Forem: Cláudio Filipe Lima Rapôso

Road to Golden Jacket: My Journey and Tips for the New AWS SOA-C03 Exam 🚀

Cláudio Filipe Lima Rapôso — Mon, 30 Mar 2026 16:15:52 +0000

When I sat down to take my AWS Certified SysOps Administrator - Associate exam on March 23, I had prepared for a broad range of operational topics. But when the test began, one thing became immediately clear: Amazon CloudWatch was everywhere.

It felt like every other scenario revolved around monitoring, analyzing logs, or troubleshooting performance bottlenecks. Now that AWS has officially transitioned to the new AWS Certified CloudOps Engineer - Associate (SOA-C03) exam, I realize that my heavy CloudWatch experience was actually the best preparation I could have asked for.

Here is a personal look at my exam experience, why CloudWatch is your best friend, and my top tips for anyone tackling the new CloudOps certification.

📈 The CloudWatch Marathon

During my exam on March 23, the monitoring and logging domain was a massive part of the test. I had to know exactly how to trigger alarms, collect logs, and automate responses.

If you are studying for the new SOA-C03 exam, this is even more critical. The domain has been expanded to "Monitoring, Logging, Analysis, Remediation, and Performance Optimization" and now carries the heaviest weight on the exam at 22%,.

To pass, you must understand how to:

Configure and manage the CloudWatch agent to collect metrics and logs not just from EC2 instances, but also from Amazon ECS and Amazon EKS clusters,.
Set up composite alarms and configure them to invoke AWS services directly or through Amazon EventBridge.
Automate remediation tasks using AWS Systems Manager Automation runbooks.

🔄 Bridging the Gap: SysOps to CloudOps

While my exam tested me heavily on traditional monitoring, the new "CloudOps" title reflects a modern shift in cloud operations. If I were taking the SOA-C03 today, here is what I would add to my study list to bridge the gap:

The Container Ecosystem: Containers are now officially in-scope. You need to understand Amazon Elastic Container Registry (ECR), Elastic Container Service (ECS), and Elastic Kubernetes Service (EKS),.
Infrastructure as Code (IaC): The new exam emphasizes creating and managing stacks using AWS CloudFormation and the AWS Cloud Development Kit (AWS CDK),.
Multi-Account Management: Operating in a single account is a thing of the past. You must know how to enforce compliance and manage security across multiple accounts using AWS Organizations, Service Control Policies (SCPs), and AWS Control Tower,.

💡 My Top Tips for Exam Day

Based on my experience in the hot seat, here are my top tips for crushing the exam:

Build a Real Monitoring Lab: Don't just read the docs. Spin up an EC2 instance, install the CloudWatch agent, and create a custom dashboard,. Set up an alarm to trigger an SNS notification or an EventBridge rule, so you see the automated flow in action.
Master Automation: Understand how to use AWS Systems Manager to automate operational processes and remediate issues,.
Eliminate the Noise: AWS questions are famously wordy and the distractors are designed to look plausible. Find the core requirement like "most cost-effective" or "highly available" and eliminate the answers that don't fit.
Embrace the AWS Well-Architected Framework: The exam tests your ability to support workloads according to these best practices,. Always think about how to optimize performance and reliability.

Taking this exam validated my practical skills and proved that I could maintain and secure workloads in the cloud. If you are preparing for the SOA-C03, dive deep into CloudWatch and embrace automation!

💡 Enjoyed it?

If you want to chat about AI, cloud, and architecture, follow me on my socials:

Social Media

I post technical content straight from the front lines. And whenever I discover a time-saving tool that gets the job done right, like this one, you'll hear about it too.

Have you taken the exam yet? Let me know your experience in the comments below! 👇

From Infrastructure to Product: Pipelines into a Profitable SaaS

Cláudio Filipe Lima Rapôso — Thu, 12 Mar 2026 19:12:31 +0000

Open Journal Systems (OJS) is the engine behind thousands of scientific publications worldwide. However, educational institutions, from high schools running literary magazines to universities managing peer-reviewed journals, share a massive pain point: they want to publish research, but they lack the internal IT resources to manage complex PHP monoliths, backups, and server security.

Blending my experience in the classroom with software architecture, I realized this is a massive opportunity. We can move beyond just "hosting" OJS and transform it into a fully automated, Zero-Touch B2B SaaS platform targeted globally at the education sector.

This article details the design, infrastructure, and product strategy to build a highly available, multi-tenant OJS SaaS on Amazon Web Services (AWS) using Terraform, Go, and GitHub Actions.

🏗️ 1. The Reference Architecture on AWS

To sell this globally, we cannot afford manual interventions or local server disks. We must adopt a distributed, stateless, and 100% managed topology.

Core Components:

Compute: Amazon ECS with AWS Fargate. We run the OJS Docker image in a serverless manner. We pay only for the CPU/RAM consumed, which is crucial for maximizing profit margins.
Database: Amazon RDS for MySQL. Fully managed, automated backups, and isolated data tiers.
File Persistence: OJS requires a persistent directory (files_dir) for articles and PDFs. We mount Amazon EFS (Elastic File System) directly to the ECS Task via the NFS protocol.

⚙️ 2. The "Zero-Touch" Provisioning Engine

To turn this infrastructure into a product, the entire customer lifecycle must be automated. Here is how the provisioning engine works:

The Storefront: A university administrator selects a plan on your landing page and checks out.
The Orchestrator (Golang API): For high concurrency and low footprint, a lightweight backend API built in Go listens for the payment gateway webhook (e.g., Stripe).
The Trigger: The Go API automatically calls the GitHub Actions API, passing the tenant_name, region, and tier as JSON payloads.
The Magic: GitHub Actions runs the Terraform scripts. Within minutes, the isolated AWS infrastructure is provisioned, Route53 updates the DNS (journal.university.edu), and the client receives an automated email with their admin credentials.

🌍 Level 1: The System Context Diagram (Business View)

Who it's for: Executives, Investors, University Directors, and non-technical Stakeholders.
What it shows: The "Big Picture." It places our OJS SaaS Platform at the center of the universe and focuses exclusively on answering two questions: Who uses the system? and What other systems do we talk to?

The Actors: It makes it clear that we have different user profiles (the Admin who pays, the Author who publishes, the Reader who consumes).
The External Boundaries: It shows that we didn't build a payment processor from scratch (we use Stripe), we didn't reinvent infrastructure pipelines (we use GitHub Actions), and we integrate with academic industry standards (Crossref).
The Value: Here, technology doesn't matter. There is no AWS, Go, or PHP in this diagram. The focus is purely on the business value flow.

Level 2: The Container Diagram (Solution/Cloud View)

Who it's for: Cloud Architects, DevOps Engineers, Tech Leads, and Security Teams.
What it shows: How the central system (the blue box from Level 1) is divided internally.
(Architectural Note: In the C4 Model, a "Container" means an independently deployable/runnable unit, not necessarily a Docker container, although in our case, they coincide).

Separation of Concerns: The division between the Storefront Web (React Front-end), the Provisioning API (our Go engine), and the Tenant Infrastructure (the client's OJS) is crystal clear.
Technology Choices: This is where the cloud "magic" appears. We show that OJS runs on ECS Fargate (Compute), uses Amazon RDS (Relational Database), and Amazon EFS (Network persistence for PDFs).
Communication Flow: It shows that the Admin doesn't access the database directly; the communication flows from the Browser to the Load Balancer, to the container, and only then to the database via port 3306.

🧩 Level 3: The Component Diagram (Engineering/Code View)

Who it's for: Software Developers (Backend).
What it shows: We take just one of the containers from Level 2 (in this case, our Go Provisioning API) and open the hood to see how the code is structured internally.

Domain Isolation: This is the perfect level to demonstrate Domain-Driven Design (DDD) principles. The Tenant Manager component represents the heart of our domain (where the business rules live).
Dependency Inversion: The diagram shows components like the GitHub API Client and the Metadata Repository. As architects, we want our domain (Tenant Manager) to not depend on specific infrastructure implementations, but rather on interfaces (ports and adapters). The visual flow shows how the business rule delegates the heavy I/O lifting to external clients.
The Webhook Lifecycle: It explains the exact path of the data: The request hits the Router, passes through validation in the Payment Handler, updates the database via the Metadata Repo, and finally triggers the infrastructure via the GitHub Client.

Here is the GitHub Actions workflow that your Go API triggers:

name: 'Zero-Touch SaaS Provisioning'
on:
  workflow_dispatch:
    inputs:
      tenant_name: { description: 'Tenant Name', required: true }
      environment: { description: 'Tier (basic/premium)', required: true }
      aws_region: { description: 'Target Region', required: true }

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Configure AWS Credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: ${{ github.event.inputs.aws_region }}

      - name: Terraform Init & Apply
        run: |
          terraform init -backend-config="key=${{ github.event.inputs.tenant_name }}.tfstate"
          terraform apply -var-file="envs/${{ github.event.inputs.environment }}.tfvars.json" -auto-approve

🌍 3. Global Scaling and Data Compliance

Selling to the global education market means navigating strict data privacy laws. Because our infrastructure is codified with Terraform, deploying a compliant environment is just a matter of dynamically injecting the aws_region variable:

GDPR (Europe): If a German university signs up, the automation deploys to eu-central-1 (Frankfurt). The data never leaves Europe.
LGPD (Brazil): For Brazilian institutions, the automation targets sa-east-1 (São Paulo).
FERPA/HIPAA (USA): Medical universities publishing clinical trials can be hosted in isolated, dedicated environments in the US.

💎 4. Tiered Product Strategy (FinOps)

We can structure the SaaS offerings to capture both ends of the academic spectrum, leveraging AWS FinOps strategies:

Tier 1: High School & Small College Plan (High Volume)

Use Case: High school science fairs or small departmental newsletters.
Architecture: Shared ECS resources and a single shared RDS instance with logical separation (different schemas per school).
FinOps: We use Fargate Spot to utilize spare AWS compute capacity for up to a 70% discount. We also use EventBridge to scale the environments down to zero during weekends and school holidays.

Tier 2: University & Research Institute Plan (High Margin)

Use Case: Official university peer-reviewed journals indexing globally with Crossref and DOIs.
Architecture: Dedicated ECS Tasks, isolated RDS instances powered by Graviton (ARM) processors for better price/performance, and custom domain mapping.
Price Point: Premium recurring revenue with strict SLA guarantees and daily automated snapshots.

🐳 5. Dockerizing OJS

The Docker image remains very similar to any standard containerized environment, focusing heavily on the required PHP extensions:

FROM php:8.2-apache

# System dependencies and PHP extensions required for OJS on AWS
RUN apt-get update && apt-get install -y \
    libpng-dev libjpeg-dev libxml2-dev libzip-dev zlib1g-dev libicu-dev g++ \
    && docker-php-ext-configure gd --with-jpeg \
    && docker-php-ext-install gd mysqli opcache zip intl gettext

# Upload Optimizations
RUN { \
    echo 'opcache.memory_consumption=128'; \
    echo 'upload_max_filesize=64M'; \
    echo 'post_max_size=64M'; \
    } > /usr/local/etc/php/conf.d/ojs-optimization.ini

COPY . /var/www/html/
RUN chown -R www-data:www-data /var/www/html/

🛠️ 6. Infrastructure as Code (Terraform)

Governance across the AWS environment is managed via Terraform. The state (.tfstate) is securely stored in Amazon S3 with State Locking handled by DynamoDB.

Below is the critical snippet that connects ECS (Fargate) to EFS to persist the PDFs:

# 1. Amazon RDS MySQL
resource "aws_db_instance" "ojs_db" {
  identifier           = "ojs-db-${var.environment}"
  allocated_storage    = 20
  engine               = "mysql"
  engine_version       = "8.0"
  instance_class       = var.db_instance_class
  username             = var.db_user
  password             = var.db_password
  vpc_security_group_ids = [aws_security_group.rds_sg.id]
  db_subnet_group_name = aws_db_subnet_group.main.name
  skip_final_snapshot  = true
}

# 2. Amazon EFS for the files directory
resource "aws_efs_file_system" "ojs_files" {
  creation_token = "ojs-efs-${var.environment}"
  encrypted      = true
}

# 3. ECS Task Definition (Fargate) with EFS Volume
resource "aws_ecs_task_definition" "ojs_task" {
  family                   = "ojs-app-${var.environment}"
  requires_compatibilities = ["FARGATE"]
  network_mode             = "awsvpc"
  cpu                      = var.fargate_cpu
  memory                   = var.fargate_memory

  container_definitions = jsonencode([{
    name  = "ojs-container"
    image = var.ecr_image_url
    mountPoints = [{
      sourceVolume  = "ojs-efs-volume"
      containerPath = "/var/www/ojsdata"
    }]
    environment = [
      { name = "MYSQL_HOST", value = aws_db_instance.ojs_db.address }
    ]
  }])

  volume {
    name = "ojs-efs-volume"
    efs_volume_configuration {
      file_system_id = aws_efs_file_system.ojs_files.id
      transit_encryption = "ENABLED"
    }
  }
}

Variable Injection (FinOps)

We define instance sizes via JSON (prod.tfvars.json) to control costs per environment:

{
  "environment": "prod",
  "region": "us-east-1",
  "fargate_cpu": "1024",
  "fargate_memory": "2048",
  "db_instance_class": "db.t4g.medium",
  "db_user": "ojsadmin"
}

🚀 7. CI/CD with GitHub Actions

The automated deployment pipeline checks out the code, configures AWS credentials, and updates the infrastructure via Terraform.

name: 'Deploy OJS AWS'
on:
  workflow_dispatch:
    inputs:
      tenant_name: { description: 'Tenant Name', required: true }
      environment: { description: 'Environment (dev/hom/prod)', required: true }

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Configure AWS Credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: us-east-1

      - name: Terraform Init (S3 Backend)
        run: |
          terraform init \
            -backend-config="bucket=ojs-terraform-state-central" \
            -backend-config="key=${{ github.event.inputs.tenant_name }}.${{ github.event.inputs.environment }}.tfstate" \
            -backend-config="dynamodb_table=terraform-lock"

      - name: Terraform Apply
        env:
          TF_VAR_db_password: ${{ secrets.DB_PASSWORD }}
        run: |
          terraform apply \
            -var-file="envs/${{ github.event.inputs.environment }}.tfvars.json" \
            -auto-approve

💰 8. FinOps: Cost Optimization on AWS

AWS provides fantastic mechanisms to slash costs in non-production environments:

Fargate Spot: In Dev/Hom environments, we configure the ECS Capacity Provider to use Fargate Spot, utilizing spare AWS compute capacity for up to a 70% discount.
Graviton (ARM): We use RDS instances powered by Graviton processors (db.t4g), which deliver better performance at a lower price point than the x86 architecture.
Scheduling Automation: We leverage Amazon EventBridge to trigger an AWS Lambda function that stops the RDS instance and scales the ECS Desired Count to 0 outside of regular business hours.

🎯 Conclusion

By bridging the gap between software architecture and the needs of the classroom, we can transform Open Journal Systems from a complex IT burden into a seamless, globally scalable SaaS product. The combination of AWS ECS Fargate for horizontal scalability, Go for rapid API orchestration, and Terraform for compliant IaC delivers a true, zero-touch EdTech platform.

Have you ever thought about productizing open-source software into a niche B2B SaaS? Share your thoughts and architectural approaches in the comments! 👇

Reason Your Python Code is Hard to Test with Single Responsibility Principle, And How to Fix It! (Portuguese version)

Cláudio Filipe Lima Rapôso — Mon, 29 Dec 2025 19:43:37 +0000

O Princípio da Responsabilidade Única (SRP - Single Responsibility Principle) é a base dos princípios SOLID. Ele estabelece que uma classe deve ter um, e apenas um, motivo para mudar.

Quando ignoramos esse princípio, criamos "God Classes" (Classes Deus) componentes que sabem demais e fazem demais. Essas classes são frágeis: uma mudança no banco de dados pode quebrar a lógica de validação, ou uma alteração nas regras de negócio pode quebrar o sistema de envio de e-mails.

Neste guia, analisaremos um antipadrão comum em uma funcionalidade de Cadastro de Usuário e a refatoraremos para uma arquitetura limpa e desacoplada.

❌ O "Antes": A Violação do SRP

Aqui está um exemplo típico de código legado. Temos uma classe chamada UserService, mas ela não está agindo como um serviço; ela age como um monolito.

Por que isso é ruim:

Alto Acoplamento: Ela está fortemente ligada a regras de validação específicas e instruções de banco de dados (print).
Difícil de Testar: Você não consegue testar a lógica de registro sem acionar a lógica do banco de dados.
Múltiplos Motivos para Mudar: Se as regras de senha mudarem, este arquivo é aberto. Se o banco de dados mudar, este arquivo também é aberto.

class UserService:
    def register(self, name, email, password):
        # Responsabilidade 1: Lógica de Validação
        if len(name) < 3:
            raise ValueError("O nome é muito curto")
        if "@" not in email:
            raise ValueError("Email inválido")
        if len(password) < 6:
            raise ValueError("A senha é muito fraca")

        # Responsabilidade 2: Lógica de Banco de Dados (Verificar existência)
        print(f"[DB] Verificando se {email} existe...")
        if email == "taken@example.com":
             raise ValueError("Email já está em uso")

        # Responsabilidade 3: Lógica de Persistência (Salvar)
        print(f"[DB] INSERT INTO users (name, email) VALUES ('{name}', '{email}')")

        # Responsabilidade 4: Lógica de Notificação
        print(f"[MAIL] Enviando e-mail de boas-vindas para {email}...")

Uso

service = UserService()
service.register("Alice", "alice@example.com", "123456")

✅ A Refatoração: Separação de Preocupações

Para corrigir isso, devemos identificar as responsabilidades distintas e extraí-las para suas próprias classes.

1. A Entidade (Estrutura de Dados)

Primeiro, criamos uma representação dos dados. Esta classe não tem lógica; ela apenas armazena estado.

Motivo para mudar: Apenas se os atributos do usuário (como adicionar telefone) mudarem.

from dataclasses import dataclass

@dataclass
class User:
    name: str
    email: str
    password: str

2. O Validador (Regras de Negócio)

Extraímos as regras de validação. Esta classe garante a integridade dos dados.

Motivo para mudar: Apenas se as regras para dados válidos mudarem.

class UserValidator:
    def validate(self, user: User):
        if len(user.name) < 3:
            raise ValueError("O nome é muito curto")
        if "@" not in user.email:
            raise ValueError("Email inválido")
        if len(user.password) < 6:
            raise ValueError("A senha é muito fraca")

3. O Repositório (Persistência)

Abstraímos as operações de banco de dados. Esta classe lida com o "Como" armazenar os dados.

Motivo para mudar: Apenas se a tecnologia do banco de dados (SQL, NoSQL, Arquivo) mudar.

class UserRepository:
    def exists(self, email: str) -> bool:
        # Simula verificação no DB
        return email == "taken@example.com"

    def save(self, user: User):
        # Simula salvamento no DB
        print(f"[DB] INSERT INTO users VALUES ('{user.name}', '{user.email}')")

4. O Serviço (O Orquestrador)

Finalmente, reescrevemos o UserService. Note como ele ficou limpo. Ele não sabe como validar ou como salvar; ele simplesmente delega essas tarefas para os especialistas (as dependências injetadas).

Motivo para mudar: Apenas se o fluxo de trabalho do cadastro mudar (ex: adicionar uma etapa para verificar o telefone via SMS).

class UserService:
    def __init__(self, validator: UserValidator, repository: UserRepository):
        # Injeção de Dependência: Pedimos as ferramentas que precisamos
        self.validator = validator
        self.repository = repository

    def register(self, name, email, password):
        user = User(name, email, password)

        # Passo 1: Validar
        self.validator.validate(user)

        # Passo 2: Verificar Regras de Negócio
        if self.repository.exists(email):
            raise ValueError("Email já está em uso")

        # Passo 3: Persistir
        self.repository.save(user)

        print(">>> Usuário registrado com sucesso.")

Exemplo de Uso

Ao conectar os componentes ("wiring"), criamos um sistema flexível.

    # 1. Configurar as dependências
    repo = UserRepository()
    val = UserValidator()

    # 2. Injetar dependências no Serviço
    service = UserService(validator=val, repository=repo)

    # 3. Executar a lógica
    try:
        service.register("Bob", "bob@example.com", "senhaSegura123")
    except ValueError as e:
        print(f"Erro: {e}")

Conclusão

Ao aplicar o Princípio da Responsabilidade Única, transformamos um script rígido em uma arquitetura de software profissional.

Os benefícios dessa abordagem são claros:

Testabilidade: Agora você pode criar testes unitários para o UserValidator isoladamente, sem precisar de um banco de dados falso.
Manutenibilidade: Se o esquema do banco de dados mudar, você edita apenas o UserRepository. O UserService permanece intocado.
Legibilidade: O UserService agora lê como uma história de alto nível sobre o que acontece, em vez de uma lista bagunçada de como acontece.

Essa separação reduz a carga cognitiva sobre o desenvolvedor e garante que sua aplicação seja robusta o suficiente para lidar com mudanças futuras com risco mínimo.

Bot de Monitoramento para SushiSwap V3 em Go — Parte 1

Cláudio Filipe Lima Rapôso — Tue, 30 Sep 2025 20:13:30 +0000

Este guia descreve, de forma contínua e didática, como construir a primeira metade de um bot de trading em Go. Nesta etapa não há transações on-chain. O programa observa o preço em dólar de um token de referência, compara esse valor com limites configurados em um arquivo .env e decide, de maneira simulada, quando compraria e quando venderia. O objetivo é validar lógica e parâmetros sem risco financeiro, além de introduzir a persistência do estado em SQLite para que o bot possa ser interrompido e retomado sem perder contexto.

Conceito e fluxo

O comportamento é simples. O aplicativo carrega as configurações do .env, consulta periodicamente o preço em USD do token de referência por HTTP e imprime no console o valor atual. Se o preço observado estiver abaixo ou igual ao alvo de compra e ainda não houver posição aberta, considera-se uma entrada e o estado é salvo no banco com a informação do preço de entrada. Se, com posição aberta, o preço atingir o alvo de lucro, considera-se a saída e o estado é atualizado para indicar que não há mais posição. Em qualquer outro caso, o programa apenas aguarda. Como não há transações nesta fase, tratamos essas decisões como um simulador de gatilhos, útil para ajustar parâmetros e entender o ciclo de execução.

Preparação do ambiente

É necessário ter Go instalado em versão recente. Crie uma pasta para o projeto, inicialize um módulo e instale as dependências. O pacote godotenv carrega variáveis do arquivo .env e o driver modernc.org/sqlite possibilita usar SQLite sem CGO, o que simplifica a portabilidade.

mkdir sushiswap-v3-go && cd sushiswap-v3-go
go mod init example.com/sushiswap-v3-go
go get github.com/joho/godotenv
go get modernc.org/sqlite

Configuração com `.env`

Crie um arquivo .env na raiz do projeto. Ele concentra variáveis de rede e parâmetros de estratégia. Também indicamos DB_PATH, o caminho do arquivo SQLite que manterá o estado.

CHAIN_ID=11155111
NETWORK=sepolia
INFURA_API_KEY=SUA_INFURA_KEY

TOKEN0_ADDRESS=0xfFf9976782d46CC05630D1f6eBAb18b2324d6B14
TOKEN1_ADDRESS=0x1c7D4B196Cb0C7B01d743Fbc6116a902379C7238

QUOTE0_ADDRESS=0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2

WALLET=0xSUA_WALLET
PRIVATE_KEY=0xSUA_PRIVATE_KEY

ROUTER_ADDRESS=0x3b0aa7d38bf3c103bf02d1de2e37568cbed3d6e8

PRICE_TO_BUY=5000
AMOUNT_TO_BUY=0.1
PROFITABILITY=1.1

DB_PATH=./bot.db

A variável QUOTE0_ADDRESS representa o token cujo preço em USD será observado; no exemplo, usa-se o WETH da mainnet por ser uma referência líquida e amplamente utilizada. As variáveis PRICE_TO_BUY e PROFITABILITY definem, respectivamente, o alvo de entrada e o multiplicador do alvo de lucro. As chaves de carteira e o endereço do router são armazenados desde já, embora só venham a ser utilizadas na fase seguinte, quando forem adicionadas transações reais. Recomenda-se manter o arquivo .env fora do controle de versão.

Implementação do código

A seguir estão os arquivos Go, organizados por responsabilidade. Basta criar cada arquivo com o conteúdo indicado.

`config.go`

Este módulo lê e valida o .env, convertendo valores numéricos e garantindo que os campos mínimos existam para a execução desta etapa. Se faltar algo essencial, a função sinaliza claramente o problema.

package main

import (
    "fmt"
    "os"
    "strconv"

    "github.com/joho/godotenv"
)

type Config struct {
    ChainID       int
    Network       string
    InfuraAPIKey  string
    Token0Address string
    Token1Address string
    Quote0Address string
    Wallet        string
    PrivateKey    string
    RouterAddress string
    PriceToBuy    float64
    AmountToBuy   string
    Profitability float64
    DBPath        string
}

func LoadConfig() (*Config, error) {
    _ = godotenv.Load()

    var err error
    cfg := &Config{}

    if v := os.Getenv("CHAIN_ID"); v != "" {
        if cfg.ChainID, err = strconv.Atoi(v); err != nil {
            return nil, fmt.Errorf("CHAIN_ID inválido: %w", err)
        }
    } else {
        cfg.ChainID = 11155111
    }

    cfg.Network = os.Getenv("NETWORK")
    cfg.InfuraAPIKey = os.Getenv("INFURA_API_KEY")
    cfg.Token0Address = os.Getenv("TOKEN0_ADDRESS")
    cfg.Token1Address = os.Getenv("TOKEN1_ADDRESS")
    cfg.Quote0Address = os.Getenv("QUOTE0_ADDRESS")
    cfg.Wallet = os.Getenv("WALLET")
    cfg.PrivateKey = os.Getenv("PRIVATE_KEY")
    cfg.RouterAddress = os.Getenv("ROUTER_ADDRESS")
    cfg.AmountToBuy = os.Getenv("AMOUNT_TO_BUY")

    if v := os.Getenv("PRICE_TO_BUY"); v != "" {
        if cfg.PriceToBuy, err = strconv.ParseFloat(v, 64); err != nil {
            return nil, fmt.Errorf("PRICE_TO_BUY inválido: %w", err)
        }
    } else {
        return nil, fmt.Errorf("PRICE_TO_BUY ausente")
    }

    if v := os.Getenv("PROFITABILITY"); v != "" {
        if cfg.Profitability, err = strconv.ParseFloat(v, 64); err != nil {
            return nil, fmt.Errorf("PROFITABILITY inválido: %w", err)
        }
    } else {
        return nil, fmt.Errorf("PROFITABILITY ausente")
    }

    if cfg.Quote0Address == "" {
        return nil, fmt.Errorf("QUOTE0_ADDRESS ausente")
    }

    if v := os.Getenv("DB_PATH"); v != "" {
        cfg.DBPath = v
    } else {
        cfg.DBPath = "./bot.db"
    }

    return cfg, nil
}

`database.go`

Este módulo cria e inicializa o banco SQLite, além de oferecer funções para ler e salvar o estado do bot. O estado se restringe a duas informações: se há ou não posição aberta e qual foi o preço de entrada, quando aplicável. Ao iniciar pela primeira vez, uma linha padrão é criada para garantir que o acesso seja simples e previsível nas execuções subsequentes.

package main

import (
    "database/sql"
    "fmt"

    _ "modernc.org/sqlite"
)

type BotState struct {
    IsOpened   bool
    EntryPrice *float64
}

func InitDB(path string) (*sql.DB, error) {
    db, err := sql.Open("sqlite", path)
    if err != nil {
        return nil, fmt.Errorf("erro abrindo sqlite: %w", err)
    }
    schema := `
    CREATE TABLE IF NOT EXISTS bot_state (
        id INTEGER PRIMARY KEY CHECK (id = 1),
        is_opened INTEGER NOT NULL,
        entry_price REAL
    );
    INSERT INTO bot_state (id, is_opened, entry_price)
        SELECT 1, 0, NULL
        WHERE NOT EXISTS (SELECT 1 FROM bot_state WHERE id = 1);
    `
    if _, err := db.Exec(schema); err != nil {
        return nil, fmt.Errorf("erro criando schema: %w", err)
    }
    return db, nil
}

func LoadBotState(db *sql.DB) (*BotState, error) {
    row := db.QueryRow(`SELECT is_opened, entry_price FROM bot_state WHERE id = 1`)
    var isOpenedInt int
    var entryPrice sql.NullFloat64
    if err := row.Scan(&isOpenedInt, &entryPrice); err != nil {
        return nil, fmt.Errorf("erro lendo estado: %w", err)
    }
    var ep *float64
    if entryPrice.Valid {
        v := entryPrice.Float64
        ep = &v
    }
    return &BotState{
        IsOpened:   isOpenedInt == 1,
        EntryPrice: ep,
    }, nil
}

func SaveBotState(db *sql.DB, st *BotState) error {
    var isOpenedInt int
    if st.IsOpened {
        isOpenedInt = 1
    } else {
        isOpenedInt = 0
    }

    var entry interface{}
    if st.EntryPrice != nil {
        entry = *st.EntryPrice
    }

    if _, err := db.Exec(
        `UPDATE bot_state SET is_opened = ?, entry_price = ? WHERE id = 1`,
        isOpenedInt, entry,
    ); err != nil {
        return fmt.Errorf("erro salvando estado: %w", err)
    }
    return nil
}

`prices.go`

Esta unidade contém a função que consulta a API pública de preços. O retorno esperado é um número de ponto flutuante representando o preço em USD do token indicado. A configuração de timeout e a verificação do status HTTP ajudam a tornar o comportamento previsível.

package main

import (
    "encoding/json"
    "fmt"
    "io"
    "net/http"
    "time"
)

func fetchPriceUSD(tokenAddress string) (float64, error) {
    url := fmt.Sprintf("https://api.sushi.com/price/v1/%d/%s", 1, tokenAddress)

    req, _ := http.NewRequest(http.MethodGet, url, nil)
    req.Header.Set("Accept", "application/json")

    client := &http.Client{Timeout: 10 * time.Second}
    res, err := client.Do(req)
    if err != nil {
        return 0, err
    }
    defer res.Body.Close()

    if res.StatusCode != http.StatusOK {
        body, _ := io.ReadAll(res.Body)
        return 0, fmt.Errorf("pricing api status %d: %s", res.StatusCode, string(body))
    }

    var price float64
    if err := json.NewDecoder(res.Body).Decode(&price); err != nil {
        return 0, fmt.Errorf("falha ao decodificar preço: %w", err)
    }
    return price, nil
}

`main.go`

O arquivo principal integra as partes. Ao iniciar, o programa carrega a configuração, prepara o banco, recupera o estado e entra em um ciclo que consulta o preço, imprime o valor e executa a lógica de decisão, atualizando o SQLite sempre que houver mudanças de estado. Um comando para limpar a tela mantém o console com aparência de painel.

package main

import (
    "fmt"
    "log"
    "time"
)

func monitor(cfg *Config) (float64, error) {
    price, err := fetchPriceUSD(cfg.Quote0Address)
    if err != nil {
        return 0, err
    }
    fmt.Print("\033[2J\033[H")
    fmt.Println("Price:", price)
    return price, nil
}

func main() {
    cfg, err := LoadConfig()
    if err != nil {
        log.Fatalf("config erro: %v", err)
    }

    db, err := InitDB(cfg.DBPath)
    if err != nil {
        log.Fatalf("db erro: %v", err)
    }
    defer db.Close()

    state, err := LoadBotState(db)
    if err != nil {
        log.Fatalf("erro carregando estado: %v", err)
    }

    cycle := func() {
        price, err := monitor(cfg)
        if err != nil {
            log.Printf("erro monitorando preço: %v", err)
            return
        }

        if !state.IsOpened && price <= cfg.PriceToBuy {
            state.IsOpened = true
            state.EntryPrice = &price
            if err := SaveBotState(db, state); err != nil {
                log.Printf("erro salvando estado (swap in): %v", err)
            }
            fmt.Printf("Swap in (entry=%.6f)\n", price)
            return
        }

        target := cfg.PriceToBuy * cfg.Profitability
        if state.IsOpened && price >= target {
            state.IsOpened = false
            state.EntryPrice = nil
            if err := SaveBotState(db, state); err != nil {
                log.Printf("erro salvando estado (swap out): %v", err)
            }
            fmt.Printf("Swap out (target=%.6f)\n", target)
            return
        }

        if state.IsOpened && state.EntryPrice != nil {
            fmt.Printf("Wait... (opened at %.6f, target %.6f)\n", *state.EntryPrice, target)
            return
        }

        fmt.Println("Wait...")
    }

    cycle()
    ticker := time.NewTicker(10 * time.Second)
    defer ticker.Stop()
    for range ticker.C {
        cycle()
    }
}

Execução

Com os arquivos criados e o .env preenchido, execute o projeto a partir da raiz. O console exibirá o preço e a decisão correspondente do ciclo. Quando o preço atingir o alvo de compra, aparecerá a indicação de entrada e o estado será salvo. Quando alcançar o alvo de lucro com posição aberta, a saída será registrada. Se o programa for encerrado e reiniciado, a leitura do banco restaurará a situação anterior.

go run .

Encerramento

Com esta base consolidada, você tem um esqueleto funcional capaz de observar preço, tomar decisões simuladas e manter consistência entre execuções por meio de SQLite. Na Parte 2, em vez de montar e enviar a transação on-chain localmente, o fluxo de swap será executado via gRPC: o cliente em Go fará chamadas a um serviço gRPC responsável por cotar e processar a operação de compra e venda. Esse serviço receberá parâmetros como chain_id, token_in, token_out, amount, max_slippage e wallet, retornará métricas de pré-troca (por exemplo, o assumedAmountOut) e cuidará da preparação/execução da transação, incluindo roteamento, montagem do payload, assinatura e envio, além do retorno do hash e do recibo quando confirmada.

Do ponto de vista de arquitetura, o cliente Go apenas disciplina a orquestração: abre o canal gRPC, envia a requisição de Quote/Execute, aguarda a resposta (com sucesso ou erro tratado) e registra estado/telemetria. O serviço gRPC concentra a lógica sensível: integração com o roteador (para encontrar a melhor rota), aplicação de slippage máxima, políticas de deadline e retries, idempotência por chave, auditoria, observabilidade e segurança de chaves (sem trafegar PRIVATE_KEY pelo cliente). A assinatura pode ficar no servidor (HSM, KMS ou cofre) ou ser separada em um signer dedicado, mantendo o cliente leve e sem material sensível.

Finalmente, a evolução natural é: o bot em Go continua decidindo quando agir, persiste o estado no SQLite, e a execução do swap passa a ser um contrato gRPC bem definido com protobufs para cotação e execução, entregando robustez operacional, isolamento de segredos e padronização de erros/logs para produção.

Referências

Go. (2025, 25 fevereiro). The Go programming language specification. go.dev. https://go.dev/ref/spec (Go)

Go. (n.d.). Documentation. go.dev. https://go.dev/doc/ (Go)

gRPC. (2024, 25 novembro). Basics tutorial | Go. grpc.io. https://grpc.io/docs/languages/go/basics/ (gRPC)

gRPC. (2024, 25 novembro). Quick start | Go. grpc.io. https://grpc.io/docs/languages/go/quickstart/ (gRPC)

Protocol Buffers. (n.d.). Protocol buffer basics: Go. protobuf.dev. https://protobuf.dev/getting-started/gotutorial/ (protobuf.dev)

Equipe go-ethereum (Geth). (2024, 24 maio). Getting started with Geth. geth.ethereum.org. https://geth.ethereum.org/docs/getting-started (go-ethereum)

Go Ethereum. (n.d.). github.com/ethereum/go-ethereum (API em Go). pkg.go.dev. https://pkg.go.dev/github.com/ethereum/go-ethereum (Go Packages)

modernc.org. (2025, 11 agosto). sqlite package (driver SQLite sem CGO). pkg.go.dev. https://pkg.go.dev/modernc.org/sqlite (Go Packages)

Joho. (n.d.). joho/godotenv [Repositório]. GitHub. https://github.com/joho/godotenv (GitHub)

Sushi. (2025, 13 setembro). Pricing API documentation. docs.sushi.com. https://docs.sushi.com/api/examples/pricing (docs.sushi.com)

gRPC-Go. (n.d.). google.golang.org/grpc (pacote em Go). pkg.go.dev. https://pkg.go.dev/google.golang.org/grpc (Go Packages)

💡Curtiu?

Se quiser trocar ideia sobre IA, cloud e arquitetura, me segue nas redes:

Redes Sociais

Publico conteúdos técnicos direto do campo de batalha. E quando descubro uma ferramenta que economiza tempo e resolve bem, como essa, você fica sabendo também.

Autenticação Segura com Microsoft Entra ID para desenvolvedores Typescript

Cláudio Filipe Lima Rapôso — Tue, 23 Sep 2025 18:32:42 +0000

Aplicações modernas funcionam raramente isoladas. Muitas vezes temos um frontend que lida com a experiência do usuário, e um backend que concentra as regras de negócio e o acesso a dados sensíveis.
Garantir que apenas usuários autenticados consigam acessar esses recursos é fundamental.

Neste artigo, vamos construir uma solução que utiliza Next.js como frontend, integrando a autenticação com o Microsoft Entra ID (antigo Azure Active Directory), e um backend em Node/TypeScript que valida tokens JWT emitidos pelo Entra ID antes de liberar o acesso a rotas protegidas.

Arquitetura Geral

A solução pode ser entendida em cinco passos principais:

O usuário acessa a aplicação em Next.js e inicia o login.
O NextAuth.js redireciona o usuário para o Microsoft Entra ID.
Após a autenticação, o Entra ID retorna um ID Token e um Access Token para o Next.js.
O frontend envia o Access Token ao backend, no header Authorization: Bearer <token>.
O backend valida o token contra o serviço de chaves públicas (JWKS) do Entra ID.

Se válido → rota protegida é acessada.
Se inválido/expirado → resposta 401 Unauthorized.

1. Configuração no Entra ID

No Azure Portal:

Vá em Microsoft Entra ID → App registrations → New registration.
Preencha os campos:
- Name: nextjs-auth-app
- Redirect URI: http://localhost:3000/api/auth/callback
- Ative ID tokens e Access tokens.
Salve as credenciais:
- Application (client) ID
- Directory (tenant) ID
- Client Secret (criado manualmente em Certificates & secrets).

2. Frontend Next.js com NextAuth

Instalação

npm install next-auth @azure/msal-node

Variáveis de ambiente

Arquivo .env.local:

AZURE_AD_CLIENT_ID=<Application ID>       # ID da aplicação registrada no Entra ID
AZURE_AD_CLIENT_SECRET=<Client Secret>    # Segredo do app (não expor no frontend)
AZURE_AD_TENANT_ID=<Directory ID>         # Tenant (diretório da organização)
NEXTAUTH_URL=http://localhost:3000        # URL da aplicação Next.js
NEXTAUTH_SECRET=<chave-aleatória>         # Chave para assinar JWT de sessão

Configuração do NextAuth

import NextAuth from "next-auth";
import AzureADProvider from "next-auth/providers/azure-ad";

// Configuração principal do NextAuth
export default NextAuth({
  providers: [
    // Habilita login com Microsoft Entra ID (Azure AD)
    AzureADProvider({
      clientId: process.env.AZURE_AD_CLIENT_ID!,        // ID do app registrado no Entra ID
      clientSecret: process.env.AZURE_AD_CLIENT_SECRET!,// Segredo do cliente (guardado no backend)
      tenantId: process.env.AZURE_AD_TENANT_ID!,        // ID do diretório (tenant)
    }),
  ],
  session: { strategy: "jwt" }, // Sessões baseadas em JWT (sem persistência no BD)
  callbacks: {
    // Callback executado ao criar/atualizar JWT
    async jwt({ token, account }) {
      if (account) token.accessToken = account.access_token; // Armazena o accessToken no token
      return token;
    },
    // Callback executado ao montar a sessão
    async session({ session, token }) {
      session.accessToken = token.accessToken as string; // Inclui o accessToken na sessão
      return session;
    },
  },
});

Componente de Login/Logout (`AuthButton.tsx`)

"use client"; // Necessário porque usamos interações de browser (signIn/signOut)

import { signIn, signOut, useSession } from "next-auth/react";

export default function AuthButton() {
  const { data: session } = useSession(); // Hook que recupera a sessão atual

  if (session) {
    // Caso o usuário esteja logado
    return (
      <button onClick={() => signOut()}>
        Sair ({session.user?.name}) {/* Mostra o nome do usuário logado */}
      </button>
    );
  }
  // Caso não esteja logado
  return (
    <button onClick={() => signIn("azure-ad")}>
      Entrar com Entra ID {/* Chama fluxo de login no Entra ID */}
    </button>
  );
}

Tela Principal (`page.tsx`)

import AuthButton from "./components/AuthButton"; // Importa o botão de login/logout
import Link from "next/link";

export default function Home() {
  return (
    <main style={{ padding: "2rem" }}>
      <h1>🔐 Demo de Autenticação com Entra ID</h1>
      {/* Botão que mostra "Entrar" ou "Sair", dependendo da sessão */}
      <AuthButton />

      <hr style={{ margin: "2rem 0" }} />

      {/* Link para acessar página protegida */}
      <Link href="/protected">
        <button>Acessar página protegida</button>
      </Link>
    </main>
  );
}

3. Server Component: Página Protegida

import { authOptions } from "../api/auth/[...nextauth]/route";
import { getServerSession } from "next-auth";

export default async function ProtectedPage() {
  // Recupera a sessão no lado do servidor
  const session = await getServerSession(authOptions);

  if (!session) {
    // Caso o usuário não esteja autenticado
    return <p>Você precisa estar logado.</p>;
  }

  // Faz requisição ao backend protegido enviando o accessToken no header
  const res = await fetch("http://localhost:4000/api/secure-data", {
    headers: {
      Authorization: `Bearer ${session.accessToken}`, // Token nunca vai para o client
    },
    cache: "no-store", // Garante que não será cacheado
  });

  const data = await res.json();

  return (
    <div>
      <h2>Olá, {session.user?.name}</h2> {/* Nome do usuário logado */}
      <pre>{JSON.stringify(data, null, 2)}</pre> {/* Dados retornados da API */}
    </div>
  );
}

4. Backend Node/TypeScript

Dependências

npm install express jwks-rsa express-jwt

Código (`src/index.ts`)

import express from "express";
import { expressjwt as jwt } from "express-jwt";
import jwksRsa from "jwks-rsa";

const app = express();
const port = 4000;

// Middleware que valida o JWT recebido
const checkJwt = jwt({
  // Define a forma de obter as chaves públicas do Entra ID
  secret: jwksRsa.expressJwtSecret({
    cache: true,                      // Cache para não buscar chave toda vez
    rateLimit: true,                  // Limite de requisições para JWKS
    jwksRequestsPerMinute: 10,        // Máx. 10 req/min
    jwksUri: `https://login.microsoftonline.com/${process.env.AZURE_AD_TENANT_ID}/discovery/v2.0/keys`,
  }) as any,
  audience: process.env.AZURE_AD_CLIENT_ID,               // Valida se o token é para este app
  issuer: `https://login.microsoftonline.com/${process.env.AZURE_AD_TENANT_ID}/v2.0`, // Origem do token
  algorithms: ["RS256"],                                  // Algoritmo esperado
});

// Rota protegida: só acessa se o JWT for válido
app.get("/api/secure-data", checkJwt, (req, res) => {
  res.json({
    message: "Autenticado ✅",
    claims: (req as any).auth, // Retorna as claims do token decodificado
  });
});

// Inicializa o servidor
app.listen(port, () =>
  console.log(`🚀 Backend rodando em http://localhost:${port}`)
);

Boas Práticas

Proteção de secrets: nunca exponha clientSecret no frontend.
Sessões seguras: use cookies httpOnly ou JWT fornecidos pelo NextAuth.
Validação rigorosa: configure corretamente audience e issuer.
Observabilidade: registre logs de falhas de autenticação.
Escalabilidade: esse padrão permite múltiplos serviços validando tokens sem depender do frontend.

Conclusão

Com essa arquitetura, garantimos um fluxo seguro de ponta a ponta:

O Next.js gerencia autenticação e sessão do usuário.
O backend Node/TS valida tokens antes de liberar dados sensíveis.
O Microsoft Entra ID centraliza a identidade, oferecendo segurança corporativa.

Esse modelo é flexível e pode ser expandido para microsserviços ou integração com APIs da Microsoft (Graph API).

Referências

Microsoft Corporation. (2024a). Microsoft identity platform documentation. Microsoft Learn.
https://learn.microsoft.com/en-us/azure/active-directory/develop/
Microsoft Corporation. (2024b). Microsoft Entra ID: Overview. Microsoft Learn.
https://learn.microsoft.com/en-us/entra/identity/
Microsoft Corporation. (2024c). Configure NextAuth.js with Azure AD. Microsoft Learn.
https://learn.microsoft.com/en-us/azure/active-directory/develop/tutorial-v2-javascript-spa
NextAuth.js. (2024). NextAuth.js Documentation.
https://next-auth.js.org/
Auth0 Inc. (2024). Introduction to JWTs.
https://auth0.com/intro-to-jwt

Criando um Sidecar em Go para acessar o Microsoft Graph via gRPC

Cláudio Filipe Lima Rapôso — Thu, 18 Sep 2025 11:20:29 +0000

O Microsoft Graph é a porta de entrada para os serviços da Microsoft 365. Ele permite acessar informações como:

Dados de usuários e grupos.
Emails e calendários do Outlook.
Arquivos no OneDrive.
Mensagens no Teams.

Mas para chamar o Graph, não basta fazer um GET com http.Client.
É necessário autenticar via Microsoft Entra ID (antigo Azure Active Directory), obter um Access Token OAuth2, e então usá-lo em cada requisição.

👉 Isso pode complicar a aplicação principal, que precisa conhecer detalhes de autenticação.
Uma solução elegante é usar o padrão Sidecar: um serviço auxiliar, rodando ao lado da aplicação, que cuida dessa complexidade.

1. O que é um Sidecar?

Imagine que você tem uma aplicação (em Go, .NET, Python, etc) que precisa acessar o Graph.

Você pode embutir a lógica de autenticação dentro dela. Mas, se várias aplicações precisarem fazer isso, você terá código duplicado em todos os lugares.

O sidecar resolve esse problema:

É um pequeno serviço separado (nesse caso em Go) que fica rodando ao lado da aplicação.
Ele fala com o Microsoft Entra ID para buscar tokens.
Ele chama o Microsoft Graph.
Ele expõe uma API simples (via gRPC) para que a aplicação principal possa apenas pedir:

"Me dê os dados do usuário X"
E o sidecar cuida do resto.

📌 Em arquiteturas Kubernetes, o sidecar roda no mesmo pod da aplicação principal.

Isso significa que a aplicação acessa o sidecar por localhost, sem depender da rede externa.

2. Arquitetura

📌 O que acontece:

A aplicação chama GetUser no sidecar.
O sidecar verifica se já tem um Access Token válido em cache.

Se não tiver, pede um novo ao Microsoft Entra ID.
1. O sidecar chama o Microsoft Graph passando o token no header.
2. O Graph devolve os dados do usuário.
3. O sidecar converte para UserResponse e devolve para a aplicação via gRPC.

3. Definindo o contrato gRPC

Antes do código Go, precisamos definir o contrato de comunicação.

Crie o arquivo graph.proto:

syntax = "proto3";

package graph;

// Serviço que o sidecar vai expor
service GraphService {
  rpc GetUser (UserRequest) returns (UserResponse);
}

// Requisição: o cliente pode passar um user_id
// Se vazio, o sidecar consulta o "me" (usuário atual)
message UserRequest {
  string user_id = 1;
}

// Resposta: dados básicos do usuário no Graph
message UserResponse {
  string id = 1;
  string display_name = 2;
  string given_name = 3;
  string surname = 4;
  string user_principal_name = 5;
}

Explicando

O serviço GraphService expõe o método GetUser.
UserRequest permite consultar um usuário específico (users/{id}) ou o próprio usuário (me).
UserResponse retorna alguns campos comuns do Graph.

Gerando código Go

Com o protoc instalado, rode:

protoc --go_out=. --go-grpc_out=. graph.proto

Isso gera os arquivos .pb.go, que contêm as interfaces gRPC que implementaremos.

4. Implementando o sidecar em Go

4.1 Estrutura base

Crie um arquivo sidecar.go:

package main

import (
    "bytes"
    "context"
    "encoding/json"
    "fmt"
    "io"
    "net"
    "net/http"
    "os"
    "sync"
    "time"

    pb "example.com/graph/proto" // ajuste para o caminho correto
    "google.golang.org/grpc"
)

const (
    tokenURL = "https://login.microsoftonline.com/%s/oauth2/v2.0/token"
    graphURL = "https://graph.microsoft.com/v1.0/%s"
)

// Servidor gRPC que vai rodar como sidecar
type server struct {
    pb.UnimplementedGraphServiceServer
    mu          sync.Mutex
    accessToken string
    expiration  time.Time
}

📌 Aqui definimos:

As constantes com os endpoints de autenticação (Entra ID) e do Graph.
Uma struct server que:
- Implementa nosso serviço gRPC.
- Guarda em memória (accessToken, expiration) o último token obtido.

4.2 Gerenciamento de Token

func (s *server) getToken(ctx context.Context) (string, error) {
    s.mu.Lock()
    defer s.mu.Unlock()

    // Se já temos token válido, reutiliza
    if time.Now().Before(s.expiration) && s.accessToken != "" {
        return s.accessToken, nil
    }

    // Senão, pede um novo token ao Entra ID
    tenantID := os.Getenv("ENTRA_TENANT_ID")
    clientID := os.Getenv("ENTRA_CLIENT_ID")
    clientSecret := os.Getenv("ENTRA_CLIENT_SECRET")

    url := fmt.Sprintf(tokenURL, tenantID)
    data := []byte(fmt.Sprintf(
        "client_id=%s&scope=https%%3A%%2F%%2Fgraph.microsoft.com%%2F.default&client_secret=%s&grant_type=client_credentials",
        clientID, clientSecret,
    ))

    req, _ := http.NewRequestWithContext(ctx, "POST", url, bytes.NewBuffer(data))
    req.Header.Set("Content-Type", "application/x-www-form-urlencoded")

    resp, err := http.DefaultClient.Do(req)
    if err != nil {
        return "", err
    }
    defer resp.Body.Close()

    body, _ := io.ReadAll(resp.Body)
    if resp.StatusCode != http.StatusOK {
        return "", fmt.Errorf("erro ao obter token: %s", string(body))
    }

    var token struct {
        AccessToken string `json:"access_token"`
        ExpiresIn   int    `json:"expires_in"`
    }
    if err := json.Unmarshal(body, &token); err != nil {
        return "", err
    }

    // Atualiza cache (renova 1 min antes do vencimento)
    s.accessToken = token.AccessToken
    s.expiration = time.Now().Add(time.Duration(token.ExpiresIn-60) * time.Second)

    return s.accessToken, nil
}

Explicando

Cache de token: o sidecar não pede token toda hora → economiza requisições.
Mutex (mu): garante que múltiplas chamadas concorrentes não façam POST ao mesmo tempo.
Renovação antecipada: 1 minuto antes de expirar, o sidecar já pede um novo.

4.3 Implementando `GetUser`

func (s *server) GetUser(ctx context.Context, req *pb.UserRequest) (*pb.UserResponse, error) {
    // 1. Garantir token válido
    token, err := s.getToken(ctx)
    if err != nil {
        return nil, err
    }

    // 2. Montar endpoint
    userEndpoint := "me"
    if req.UserId != "" {
        userEndpoint = "users/" + req.UserId
    }

    url := fmt.Sprintf(graphURL, userEndpoint)
    httpReq, _ := http.NewRequestWithContext(ctx, "GET", url, nil)
    httpReq.Header.Set("Authorization", "Bearer "+token)

    // 3. Fazer requisição ao Microsoft Graph
    resp, err := http.DefaultClient.Do(httpReq)
    if err != nil {
        return nil, err
    }
    defer resp.Body.Close()

    body, _ := io.ReadAll(resp.Body)
    if resp.StatusCode != http.StatusOK {
        return nil, fmt.Errorf("erro ao buscar usuário: %s", string(body))
    }

    // 4. Mapear resposta para nosso UserResponse
    var user map[string]interface{}
    if err := json.Unmarshal(body, &user); err != nil {
        return nil, err
    }

    return &pb.UserResponse{
        Id:                user["id"].(string),
        DisplayName:       user["displayName"].(string),
        GivenName:         user["givenName"].(string),
        Surname:           user["surname"].(string),
        UserPrincipalName: user["userPrincipalName"].(string),
    }, nil
}

Explicando

Pega o token em cache (ou renova).
Define o endpoint (/me ou /users/{id}).
Faz um GET no Microsoft Graph.
Converte a resposta JSON para a struct UserResponse.

4.4 Subindo o servidor gRPC

func main() {
    lis, err := net.Listen("tcp", ":50051")
    if err != nil {
        panic(err)
    }
    grpcServer := grpc.NewServer()
    pb.RegisterGraphServiceServer(grpcServer, &server{})
    fmt.Println("Sidecar Microsoft Graph rodando em :50051")
    if err := grpcServer.Serve(lis); err != nil {
        panic(err)
    }
}

Explicando

O sidecar ouve na porta 50051.
Ele registra o serviço GraphService.
Ele fica rodando, pronto para responder às chamadas gRPC da aplicação principal.

5. Executando

Configure variáveis de ambiente:

   export ENTRA_CLIENT_ID="seu-client-id"
   export ENTRA_CLIENT_SECRET="seu-client-secret"
   export ENTRA_TENANT_ID="seu-tenant-id"

Rode o sidecar:

   go run sidecar.go

Teste com grpcurl:

   grpcurl -plaintext -d '{}' localhost:50051 graph.GraphService/GetUser

6. Exemplo de resposta

{
  "id": "1234abcd-...",
  "display_name": "João Silva",
  "given_name": "João",
  "surname": "Silva",
  "user_principal_name": "joao@empresa.com"
}

7. Por que usar Sidecar?

Simplicidade: a aplicação só chama gRPC, sem se preocupar com OAuth2.
Reuso: múltiplos serviços podem compartilhar o mesmo sidecar.
Segurança: credenciais ficam apenas no sidecar.
Escalabilidade: sidecars podem ser replicados em pods diferentes.
Observabilidade: métricas e logs podem ser centralizados no sidecar.

Conclusão

Criamos um sidecar em Go que:

Autentica no Microsoft Entra ID via Client Credentials Flow.
Usa o Microsoft Graph para consultar usuários.
Exponde um serviço gRPC simples para a aplicação principal.

Com isso, conseguimos um design mais limpo, seguro e escalável, separando responsabilidades e aproveitando os benefícios do padrão Sidecar.

💡Curtiu?

Se quiser trocar ideia sobre IA, cloud e arquitetura, me segue nas redes:

Redes Sociais

Publico conteúdos técnicos direto do campo de batalha. E quando descubro uma ferramenta que economiza tempo e resolve bem, como essa, você fica sabendo também.

[Boost]

Cláudio Filipe Lima Rapôso — Thu, 11 Sep 2025 19:35:04 +0000

Edesan Tomaz

Sep 11 '25

From a Roundtable Chat to an MVP Journey: Insights and Community Spirit

Comments

1 min read

🚀 Renovação Concluída!

Cláudio Filipe Lima Rapôso — Fri, 29 Aug 2025 21:53:54 +0000

Acabei de renovar minha certificação Microsoft Certified: Especialista em Arquiteto de Soluções do Azure (AZ-305) com 92% de acerto ✅

Essa renovação reforça meu compromisso contínuo em projetar soluções modernas e escaláveis na nuvem, dominando temas fundamentais que foram avaliados, como:

Design de infraestrutura: VNets, sub-redes, conectividade híbrida e alta disponibilidade.

Armazenamento e dados: escolha de camadas de Blob, Data Lake, SQL Database, Cosmos DB e estratégias de segurança.

Identidade e segurança: Key Vault, RBAC, autenticação e criptografia.

Escalabilidade e resiliência: App Services, Kubernetes, Load Balancer, Front Door, Traffic Manager e estratégias multirregião.

Integração e mensageria: Service Bus, Event Grid, Event Hubs e filas para aplicações distribuídas.

🎯 Essa jornada não é apenas sobre certificação, mas sobre ajudar empresas e equipes a tirar o máximo do Azure, unindo performance, segurança e governança.

🔗 Mais um passo rumo à evolução contínua na arquitetura de soluções em nuvem! ☁️

Break News!

Cláudio Filipe Lima Rapôso — Wed, 27 Aug 2025 11:18:20 +0000

🚀Microsoft Acabou de disponibilizar o GPT-5 no Azure OpenAI Service via Azure AI Foundry.
As possibilidades para criar soluções mais inteligentes, rápidas e context-aware subiram de nível.

Por que isso importa?

Integração simples com serviços Azure

Segurança e governança em escala empresarial

Observabilidade e ciclo de vida de prompts/modelos num só lugar

Bora explorar juntos? 💡🤖

Construindo um Bot de Trailing Stop com Go, RabbitMQ e Bounded Contexts

Cláudio Filipe Lima Rapôso — Mon, 25 Aug 2025 12:16:01 +0000

Você quer proteger seus lucros sem vigiar o gráfico o dia todo. Um Trailing Stop faz exatamente isso: acompanha o movimento favorável do preço e, ao detectar uma reversão além de um percentual configurado, fecha a posição automaticamente. Mas depender de uma ordem nativa da corretora pode ser limitante (parâmetros, disponibilidade, validações). E um monólito que faz de tudo fica difícil de escalar e observar.

Nossa proposta: um sistema distribuído e desacoplado, onde cada parte cuida de uma responsabilidade única, comunicando-se por mensagens. Assim, trocamos rigidez por flexibilidade e evolutividade.

O que vamos construir (foto geral)

MarketData: um serviço que ouve o WebSocket da Binance e publica preços em tempo real.
Orchestrator: o cérebro da estratégia. Mantém topo/fundo, calcula a variação e decide quando enviar uma ordem.
Orders: recebe comandos do orquestrador, envia a ordem à corretora (ou simula) e publica o resultado.
RabbitMQ: nosso barramento, com três exchanges: marketdata.events (fanout), order.commands (direct) e order.events (fanout).
OpenTelemetry: pronto para instrumentação e tracing (arquivo internal/tracing/otel.go).

Decisões arquiteturais-chave

Bounded contexts para separação de responsabilidades e escala independente.
Mensageria para desacoplamento (produtores não sabem quem consome e vice-versa).
Contratos de mensagens estáveis entre serviços (PriceTick, PlaceOrder, OrderResult).
Execução simulável: sem credenciais, ainda validamos o fluxo com segurança.

Pré-requisitos

Go 1.22+
Docker e Docker Compose
Conta na Binance Spot Testnet (opcional para simulação; obrigatório para ordens reais)

1. Iniciando o projeto

Estrutura do repositório:

trailingstop-bc/
├─ .env.example
├─ docker-compose.yml
├─ go.mod / go.sum
├─ cmd/
│  ├─ marketdata/
│  ├─ orchestrator/
│  └─ order/
└─ internal/
   ├─ messaging/
   ├─ tracing/
   └─ types/

`go.mod`

Define módulo e dependências. O nome do módulo acompanha o repositório.

module github.com/sertaoseracloud/trailingstop-bc

go 1.22

require (
    github.com/adshao/go-binance/v2 v2.8.5
    github.com/rabbitmq/amqp091-go v1.10.0
)

Por quê?

go-binance dá acesso a REST/WS da Binance.
amqp091-go é o cliente AMQP para o RabbitMQ.

2. Contratos de mensagens (fontes da verdade entre serviços)

`internal/types/messages.go`

package types

import "time"

// PriceTick é publicado pelo MarketData.
type PriceTick struct {
    Symbol string  `json:"symbol"`
    Price  float64 `json:"price"`
    Ts     int64   `json:"ts"`
}

// PlaceOrder é comando do Orchestrator para Orders.
type PlaceOrder struct {
    Symbol   string  `json:"symbol"`
    Side     string  `json:"side"`   // "BUY" | "SELL"
    Qty      float64 `json:"qty"`
    Type     string  `json:"type"`   // "MARKET" | "LIMIT"
    ClientID string  `json:"clientId,omitempty"`
}

// OrderResult é evento de confirmação/erro do Orders.
type OrderResult struct {
    Symbol    string  `json:"symbol"`
    Side      string  `json:"side"`
    Status    string  `json:"status"`
    OrderID   int64   `json:"orderId"`
    FilledQty float64 `json:"filledQty"`
    Price     float64 `json:"price"`
    Ts        int64   `json:"ts"`
    Error     string  `json:"error,omitempty"`
}

func NowMs() int64 { return time.Now().UnixMilli() }

Decisão: mensagens simples em JSON. Isso facilita observabilidade, reprocessamento e compatibilidade com outras linguagens.

3. Camada de mensageria (encapsulando RabbitMQ)

`internal/messaging/rabbitmq.go`

package messaging

import (
    "context"
    "encoding/json"
    "log"
    "os"
    "time"

    amqp "github.com/rabbitmq/amqp091-go"
)

const (
    ExMarketData = "marketdata.events" // fanout
    ExOrderCmds  = "order.commands"    // direct
    ExOrderEvts  = "order.events"      // fanout
)

type Bus struct{
    Conn *amqp.Connection
    Ch   *amqp.Channel
}

func MustBus() *Bus {
    url := os.Getenv("AMQP_URL")
    if url == "" { url = "amqp://guest:guest@localhost:5672/" }

    conn, err := amqp.Dial(url)
    if err != nil { log.Fatalf("amqp dial: %v", err) }
    ch, err := conn.Channel()
    if err != nil { log.Fatalf("amqp channel: %v", err) }

    must(ch.ExchangeDeclare(ExMarketData, "fanout", true, false, false, false, nil))
    must(ch.ExchangeDeclare(ExOrderCmds,  "direct", true, false, false, false, nil))
    must(ch.ExchangeDeclare(ExOrderEvts,  "fanout", true, false, false, false, nil))

    return &Bus{Conn: conn, Ch: ch}
}

func must(err error) { if err != nil { log.Fatal(err) } }

func (b *Bus) Close() { _ = b.Ch.Close(); _ = b.Conn.Close() }

func (b *Bus) PublishJSON(ex, key string, v any) error {
    body, err := json.Marshal(v)
    if err != nil { return err }
    ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
    defer cancel()
    return b.Ch.PublishWithContext(ctx, ex, key, false, false, amqp.Publishing{
        ContentType: "application/json",
        DeliveryMode: amqp.Persistent,
        Body:         body,
        Timestamp:    time.Now(),
    })
}

// Consumo fanout: fila efêmera/exclusiva para broadcast (ideal para market data).
func (b *Bus) ConsumeFanout(ex string) (<-chan amqp.Delivery, func()) {
    q, err := b.Ch.QueueDeclare("", false, true, true, false, nil)
    must(err)
    must(b.Ch.QueueBind(q.Name, "", ex, false, nil))
    msgs, err := b.Ch.Consume(q.Name, "", true, true, false, false, nil)
    must(err)
    cancel := func(){ _ = b.Ch.QueueUnbind(q.Name, "", ex, nil); _ = b.Ch.QueueDelete(q.Name, false, false, true) }
    return msgs, cancel
}

// Consumo direct: fila durável com routing key (ideal para comandos de ordem).
func (b *Bus) ConsumeDirect(ex, queue, key string) (<-chan amqp.Delivery, error) {
    q, err := b.Ch.QueueDeclare(queue, true, false, false, false, nil)
    if err != nil { return nil, err }
    if err = b.Ch.QueueBind(q.Name, key, ex, false, nil); err != nil { return nil, err }
    return b.Ch.Consume(q.Name, "", true, false, false, false, nil)
}

Decisão: abstrair conexão/publicação/consumo torna os serviços mais legíveis e reduz repetição.

4. MarketData: consumindo a Binance em tempo real

`cmd/marketdata/main.go`

package main

import (
    "log"
    "os"
    "strconv"

    binance "github.com/adshao/go-binance/v2"

    "github.com/sertaoseracloud/trailingstop-bc/internal/messaging"
    "github.com/sertaoseracloud/trailingstop-bc/internal/types"
)

func main() {
    symbol := os.Getenv("SYMBOL")
    if symbol == "" { symbol = "BTCUSDT" }

    if os.Getenv("BINANCE_TESTNET") == "true" {
        binance.UseTestnet = true
    }

    bus := messaging.MustBus()
    defer bus.Close()

    log.Printf("[marketdata] WS AggTrade %s (testnet=%v)", symbol, binance.UseTestnet)

    handler := func(e *binance.WsAggTradeEvent) {
        price, err := strconv.ParseFloat(e.Price, 64)
        if err != nil { return }
        tick := types.PriceTick{ Symbol: symbol, Price: price, Ts: types.NowMs() }
        _ = bus.PublishJSON(messaging.ExMarketData, "", tick)
    }
    errHandler := func(err error) { log.Printf("ws err: %v", err) }

    doneC, stopC, err := binance.WsAggTradeServe(symbol, handler, errHandler)
    if err != nil { log.Fatal(err) }
    <-doneC; close(stopC)
}

Por quê assim?

O canal AggTrade traz um fluxo rico de preços.
Publicar em marketdata.events (fanout) permite múltiplos consumidores (ex.: backtests, dashboards) sem acoplamento.

5. Orchestrator: o cérebro do trailing

`cmd/orchestrator/main.go`

package main

import (
    "encoding/json"
    "log"
    "math"
    "os"
    "strconv"
    "strings"

    "github.com/sertaoseracloud/trailingstop-bc/internal/messaging"
    "github.com/sertaoseracloud/trailingstop-bc/internal/types"
)

func getenvf(key string, def float64) float64 {
    v := os.Getenv(key); if v == "" { return def }
    f, err := strconv.ParseFloat(v, 64); if err != nil { return def }
    return f
}

func main(){
    symbol := os.Getenv("SYMBOL"); if symbol == "" { symbol = "BTCUSDT" }
    side := strings.ToUpper(os.Getenv("SIDE")); if side == "" { side = "SELL" }
    qty := getenvf("QTY", 0.001)
    trailing := getenvf("TRAILING_PERCENT", 1.0)
    activation := getenvf("ACTIVATION_PRICE", 0)

    bus := messaging.MustBus(); defer bus.Close()
    msgs, cancel := bus.ConsumeFanout(messaging.ExMarketData); defer cancel()

    log.Printf("[orchestrator] %s side=%s qty=%.6f trailing=%.4f%% activation=%.4f", symbol, side, qty, trailing, activation)

    activated := false
    ref := 0.0 // topo (SELL) ou fundo (BUY)
    fired := false

    for d := range msgs {
        var tick types.PriceTick
        if err := json.Unmarshal(d.Body, &tick); err != nil || tick.Symbol != symbol { continue }
        p := tick.Price

        if !activated {
            if activation == 0 || (side == "SELL" && p >= activation) || (side == "BUY" && p <= activation) {
                activated, ref = true, p
                log.Printf("[orchestrator] ativado em %.8f", p)
            }
            continue
        }

        if side == "SELL" {
            if p > ref { ref = p } // atualiza topo
            drop := (ref - p) / ref * 100
            if !fired && drop >= trailing {
                cmd := types.PlaceOrder{ Symbol: symbol, Side: "SELL", Qty: qty, Type: "MARKET" }
                _ = bus.PublishJSON(messaging.ExOrderCmds, "place_order", cmd)
                fired = true
                log.Printf("[orchestrator] disparo SELL: topo=%.8f atual=%.8f queda=%.4f%%", ref, p, drop)
            }
        } else { // BUY
            if ref == 0 || p < ref { ref = p } // guarda fundo
            rise := (p - ref) / math.Max(ref, 1e-9) * 100
            if !fired && rise >= trailing {
                cmd := types.PlaceOrder{ Symbol: symbol, Side: "BUY", Qty: qty, Type: "MARKET" }
                _ = bus.PublishJSON(messaging.ExOrderCmds, "place_order", cmd)
                fired = true
                log.Printf("[orchestrator] disparo BUY: fundo=%.8f atual=%.8f alta=%.4f%%", ref, p, rise)
            }
        }
    }
}

Decisão: a estratégia roda dentro do orquestrador (e não na corretora). Isso nos dá controle total, facilita simulação e permite trocar regras sem tocar em MarketData ou Orders.

6. Orders: a ponte com a corretora

`cmd/order/main.go`

package main

import (
    "context"
    "encoding/json"
    "log"
    "os"
    "strconv"

    binance "github.com/adshao/go-binance/v2"

    "github.com/sertaoseracloud/trailingstop-bc/internal/messaging"
    "github.com/sertaoseracloud/trailingstop-bc/internal/types"
)

func main(){
    if os.Getenv("BINANCE_TESTNET") == "true" { binance.UseTestnet = true }
    apiKey, apiSecret := os.Getenv("BINANCE_API_KEY"), os.Getenv("BINANCE_API_SECRET")

    bus := messaging.MustBus(); defer bus.Close()
    msgs, err := bus.ConsumeDirect(messaging.ExOrderCmds, "orders.place", "place_order")
    if err != nil { log.Fatal(err) }

    client := binance.NewClient(apiKey, apiSecret)
    log.Printf("[order] pronto (testnet=%v)", binance.UseTestnet)

    for d := range msgs {
        var cmd types.PlaceOrder
        if err := json.Unmarshal(d.Body, &cmd); err != nil { continue }

        res := types.OrderResult{ Symbol: cmd.Symbol, Side: cmd.Side, Ts: types.NowMs() }

        if apiKey == "" || apiSecret == "" {
            res.Status, res.FilledQty = "SIMULATED", cmd.Qty
            _ = bus.PublishJSON(messaging.ExOrderEvts, "", res)
            log.Printf("[order] (simulado) %s %f %s", cmd.Side, cmd.Qty, cmd.Symbol)
            continue
        }

        sideType := binance.SideTypeSell; if cmd.Side == "BUY" { sideType = binance.SideTypeBuy }
        svc := client.NewCreateOrderService().
            Symbol(cmd.Symbol).
            Side(sideType).
            Type(binance.OrderTypeMarket).
            Quantity(strconv.FormatFloat(cmd.Qty, 'f', -1, 64))

        ord, err := svc.Do(context.Background())
        if err != nil {
            res.Status, res.Error = "REJECTED", err.Error()
            _ = bus.PublishJSON(messaging.ExOrderEvts, "", res)
            log.Printf("[order] erro: %v", err)
            continue
        }

        res.Status, res.OrderID = string(ord.Status), ord.OrderID
        _ = bus.PublishJSON(messaging.ExOrderEvts, "", res)
        log.Printf("[order] enviado %s qty=%s symbol=%s id=%d status=%s", cmd.Side, ord.OrigQuantity, cmd.Symbol, ord.OrderID, ord.Status)
    }
}

Decisões

Dry-run automático: sem chaves, o serviço publica um OrderResult simulado.
MARKET por simplicidade: evita detalhes de filters; você pode evoluir para ordens nativas de trailing depois.

7. Observabilidade (OpenTelemetry)

`internal/tracing/otel.go` (exemplo mínimo)

package tracing

import (
    "context"
    "log"

    "go.opentelemetry.io/otel"
    "go.opentelemetry.io/otel/exporters/stdout/stdouttrace"
    sdktrace "go.opentelemetry.io/otel/sdk/trace"
)

func Init() func(context.Context) error {
    exp, err := stdouttrace.New(stdouttrace.WithPrettyPrint())
    if err != nil { log.Fatalf("otel exporter: %v", err) }

    tp := sdktrace.NewTracerProvider(
        sdktrace.WithBatcher(exp),
    )
    otel.SetTracerProvider(tp)

    return tp.Shutdown
}

Por quê?

Facilita acompanhar o caminho de uma ordem e diagnosticar gargalos.

8. Docker Compose e configuração

`.env.example`

AMQP_URL=amqp://guest:guest@rabbitmq:5672/
SYMBOL=BTCUSDT
BINANCE_TESTNET=true
SIDE=SELL
QTY=0.001
TRAILING_PERCENT=1.0
ACTIVATION_PRICE=0
BINANCE_API_KEY=
BINANCE_API_SECRET=

`docker-compose.yml`

version: "3.9"
services:
  rabbitmq:
    image: rabbitmq:3.12-management
    ports:
      - "5672:5672"
      - "15672:15672"
    healthcheck:
      test: ["CMD", "rabbitmq-diagnostics", "-q", "ping"]
      interval: 10s
      timeout: 5s
      retries: 5

  marketdata:
    build: ./cmd/marketdata
    environment:
      - AMQP_URL=${AMQP_URL}
      - SYMBOL=${SYMBOL}
      - BINANCE_TESTNET=${BINANCE_TESTNET}
    depends_on:
      rabbitmq:
        condition: service_healthy

  orchestrator:
    build: ./cmd/orchestrator
    environment:
      - AMQP_URL=${AMQP_URL}
      - SYMBOL=${SYMBOL}
      - SIDE=${SIDE}
      - QTY=${QTY}
      - TRAILING_PERCENT=${TRAILING_PERCENT}
      - ACTIVATION_PRICE=${ACTIVATION_PRICE}
    depends_on:
      rabbitmq:
        condition: service_healthy

  order:
    build: ./cmd/order
    environment:
      - AMQP_URL=${AMQP_URL}
      - BINANCE_TESTNET=${BINANCE_TESTNET}
      - BINANCE_API_KEY=${BINANCE_API_KEY}
      - BINANCE_API_SECRET=${BINANCE_API_SECRET}
    depends_on:
      rabbitmq:
        condition: service_healthy

Dicas rápidas

UI do RabbitMQ em http://localhost:15672 (guest/guest).
Escale serviços conforme a carga:

  docker compose up --build --scale orchestrator=2 --scale order=2

9. Rodando e validando

Crie o .env a partir do exemplo e ajuste parâmetros.
Suba tudo com docker compose up --build.
Observe nos logs:

marketdata: conexão WS e publicação de PriceTick.
orchestrator: ativação da estratégia, atualização de topo/fundo e disparo quando TRAILING_PERCENT é atingido.
order: ordem simulada (sem chaves) ou real (com chaves), seguido de OrderResult.

Sanidade: se o mercado estiver parado, ajuste TRAILING_PERCENT para valores menores ou teste em outro SYMBOL.

10. Para onde ir a partir daqui

Trailing nativo: migrar envio para tipos de ordem que aceitam trailingDelta.
Múltiplos pares: instâncias por símbolo com routing key específica.
Persistência: salvar estado do trailing (Redis/Postgres) para tolerância a falhas.
Observabilidade pro: Prometheus + Grafana, traces para latências por etapa.

Conclusão

Você construiu um bot de trailing stop moderno, desacoplado e observável. Mais importante: entendeu por que cada peça existe. A partir daqui, dá para adaptar a estratégia, integrar novas exchanges, ou evoluir para ordens nativas — tudo sem desmontar o resto do sistema. Bora operar com segurança e arquitetura bem pensada? 🙌

💡Curtiu?

Se quiser trocar ideia sobre IA, cloud e arquitetura, me segue nas redes:

Publico conteúdos técnicos direto do campo de batalha. E quando descubro uma ferramenta que economiza tempo e resolve bem, como essa, você fica sabendo também.

E-mails de verificação com AWS SES + Lambda (Node.js) e Terraform: do zero ao envio

Cláudio Filipe Lima Rapôso — Mon, 18 Aug 2025 21:43:30 +0000

Eu quero te levar do zero até uma solução funcional de verificação de e-mail, sem depender de servidores próprios. Vamos usar AWS SES para enviar os e-mails, DynamoDB para guardar tokens com TTL, e AWS Lambda (Node.js) para orquestrar tudo. A infraestrutura nasce com Terraform usando módulos separados (SES, DynamoDB, IAM, Lambda), mantendo o código limpo e fácil de evoluir.

O problema e a solução

Toda aplicação que cria contas precisa verificar e-mails. Fazer isso na unha costuma gerar acoplamento, scripts soltos e dor de cabeça com credenciais. Aqui eu:

Provisiono a infraestrutura como código.
Centralizo envios no SES com remetente verificado.
Persisto tokens no DynamoDB com expiração automática via TTL.
Exponho uma Lambda com Function URL que:
- POST /send: gera token, salva no DynamoDB e envia e-mail de verificação.
- GET /verify?email=...&token=...: valida token e marca como verificado.

Resultado: um fluxo completo, serverless, barato e pronto para plugar no front-end.

Observação importante: se sua conta SES estiver em sandbox, você precisa verificar o remetente e também os destinatários de teste, ou usar o mailbox simulator. Quando for para produção, peça saída de sandbox.

Arquitetura (visão rápida)

Lambda (Node.js) com Function URL pública.
SES com identidade de e-mail verificada (remetente).
DynamoDB com chave composta pk (e-mail) + sk (token) e expiresAt como TTL.
IAM Roles/Policies mínimos: DynamoDB R/W na tabela e SES SendEmail.

Pré-requisitos

Node.js 18+ (usarei runtime nodejs20.x na Lambda).
Terraform 1.6+.
AWS CLI configurado.
Uma caixa de e-mail para verificar como remetente no SES.

Estrutura de pastas

ses-dynamodb-lambda-verification/
  infra/
    main.tf
    variables.tf
    outputs.tf
    modules/
      ses/
        main.tf
        variables.tf
        outputs.tf
      dynamodb/
        main.tf
        variables.tf
        outputs.tf
      iam/
        main.tf
        variables.tf
        outputs.tf
      lambda/
        main.tf
        variables.tf
        outputs.tf
  app/
    package.json
    src/
      core/env.js
      domain/types.js
      services/email/email-client.js
      services/email/email-service.js
      services/token/token-service.js
      services/store/repository.js
      usecases/send-verification.js
      usecases/verify-token.js
      handler.js
    build.sh

Eu separei responsabilidades por módulos Terraform e camadas de código na Lambda, seguindo SOLID/DRY/YAGNI.

Infra com Terraform

1) Root: `infra/main.tf`

terraform {
  required_version = ">= 1.6.0"
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.50"
    }
  }
}

provider "aws" {
  region = var.aws_region
}

locals {
  name_prefix = "${var.project_name}-${var.environment}"
}

module "ses" {
  source        = "./modules/ses"
  sender_email  = var.sender_email
  name_prefix   = local.name_prefix
}

module "dynamodb" {
  source        = "./modules/dynamodb"
  table_name    = "${local.name_prefix}-verifications"
}

module "iam" {
  source              = "./modules/iam"
  name_prefix         = local.name_prefix
  dynamodb_table_arn  = module.dynamodb.table_arn
  ses_send_actions    = ["ses:SendEmail", "ses:SendRawEmail"]
}

module "lambda" {
  source          = "./modules/lambda"
  name_prefix     = local.name_prefix
  role_arn        = module.iam.lambda_role_arn
  artifact_path   = var.lambda_artifact_path
  env_map = {
    TABLE_NAME        = module.dynamodb.table_name
    SES_SENDER        = var.sender_email
    VERIFY_BASE_URL   = var.verify_base_url
    TOKEN_TTL_SECONDS = tostring(var.token_ttl_seconds)
    AWS_NODEJS_CONNECTION_REUSE_ENABLED = "1"
  }
}

output "function_url" {
  value       = module.lambda.function_url
  description = "URL pública da Lambda"
}

2) Root: `infra/variables.tf`

variable "aws_region" { type = string }
variable "project_name" { type = string }
variable "environment" { type = string }
variable "sender_email" { type = string }
variable "verify_base_url" { type = string, default = "" }
variable "lambda_artifact_path" { type = string }
variable "token_ttl_seconds" { type = number, default = 900 }

3) Root: `infra/outputs.tf`

output "table_name" { value = module.dynamodb.table_name }
output "function_url" { value = module.lambda.function_url }

Módulo SES: `infra/modules/ses/main.tf`

variable "sender_email" { type = string }
variable "name_prefix"  { type = string }

resource "aws_sesv2_email_identity" "this" {
  email_identity = var.sender_email
}

output "identity_arn" {
  value = aws_sesv2_email_identity.this.arn
}

A identidade de e-mail do SES v2 é gerenciada pelo recurso aws_sesv2_email_identity.

Módulo DynamoDB: `infra/modules/dynamodb/main.tf`

variable "table_name" { type = string }

resource "aws_dynamodb_table" "this" {
  name         = var.table_name
  billing_mode = "PAY_PER_REQUEST"
  hash_key     = "pk"
  range_key    = "sk"

  attribute { name = "pk" type = "S" }
  attribute { name = "sk" type = "S" }

  ttl {
    attribute_name = "expiresAt"
    enabled        = true
  }
}

output "table_name" { value = aws_dynamodb_table.this.name }
output "table_arn"  { value = aws_dynamodb_table.this.arn }

O bloco ttl { attribute_name = "expiresAt" enabled = true } habilita expiração automática de itens. A remoção é assíncrona e não consome WCU.

Módulo IAM: `infra/modules/iam/main.tf`

variable "name_prefix"         { type = string }
variable "dynamodb_table_arn"  { type = string }
variable "ses_send_actions"    { type = list(string) }

data "aws_iam_policy_document" "assume" {
  statement {
    actions = ["sts:AssumeRole"]
    principals { type = "Service" identifiers = ["lambda.amazonaws.com"] }
  }
}

resource "aws_iam_role" "lambda" {
  name               = "${var.name_prefix}-lambda-role"
  assume_role_policy = data.aws_iam_policy_document.assume.json
}

data "aws_iam_policy_document" "lambda_policy" {
  statement {
    actions   = var.ses_send_actions
    resources = ["*"]
  }
  statement {
    actions   = ["dynamodb:PutItem", "dynamodb:GetItem", "dynamodb:UpdateItem"]
    resources = [var.dynamodb_table_arn]
  }
  statement {
    actions   = ["logs:CreateLogGroup", "logs:CreateLogStream", "logs:PutLogEvents"]
    resources = ["*"]
  }
}

resource "aws_iam_policy" "lambda_inline" {
  name   = "${var.name_prefix}-lambda-policy"
  policy = data.aws_iam_policy_document.lambda_policy.json
}

resource "aws_iam_role_policy_attachment" "attach" {
  role       = aws_iam_role.lambda.name
  policy_arn = aws_iam_policy.lambda_inline.arn
}

output "lambda_role_arn" { value = aws_iam_role.lambda.arn }

Módulo Lambda: `infra/modules/lambda/main.tf`

variable "name_prefix"   { type = string }
variable "role_arn"      { type = string }
variable "artifact_path" { type = string }
variable "env_map"       { type = map(string) }

resource "aws_lambda_function" "app" {
  function_name = "${var.name_prefix}-verification"
  role          = var.role_arn
  filename      = var.artifact_path
  handler       = "handler.handler"
  runtime       = "nodejs20.x"
  timeout       = 10
  memory_size   = 256

  environment {
    variables = var.env_map
  }

  source_code_hash = filebase64sha256(var.artifact_path)
}

resource "aws_lambda_function_url" "public" {
  function_name      = aws_lambda_function.app.function_name
  authorization_type = "NONE"
}

output "function_name" { value = aws_lambda_function.app.function_name }
output "function_url"  { value = aws_lambda_function_url.public.function_url }

Function URL deixa a Lambda acessível por HTTP diretamente, com authorization_type = "NONE" para simplificar o teste.

Lambda (Node.js) — código de aplicação

`app/package.json`

{
  "name": "email-verification",
  "version": "1.0.0",
  "type": "module",
  "main": "src/handler.js",
  "scripts": {
    "zip": "rm -f function.zip && cd app && zip -r ../function.zip . -x \"*.zip\""
  },
  "dependencies": {
    "@aws-sdk/client-sesv2": "^3.640.0",
    "@aws-sdk/client-dynamodb": "^3.640.0",
    "@aws-sdk/lib-dynamodb": "^3.640.0"
  }
}

A Lambda usa SESv2 com SendEmailCommand do SDK v3.

`app/src/core/env.js`

export const env = {
  tableName: process.env.TABLE_NAME,
  sender: process.env.SES_SENDER,
  verifyBaseUrl: process.env.VERIFY_BASE_URL || "",
  tokenTtlSeconds: Number(process.env.TOKEN_TTL_SECONDS || "900")
};

`app/src/domain/types.js`

export const Status = Object.freeze({ Pending: "pending", Verified: "verified" });

`app/src/services/token/token-service.js`

import crypto from "crypto";

export function generateToken() {
  return crypto.randomBytes(32).toString("base64url");
}

export function expirationEpoch(secondsFromNow) {
  const now = Math.floor(Date.now() / 1000);
  return now + secondsFromNow;
}

`app/src/services/email/email-client.js`

import { SESv2Client } from "@aws-sdk/client-sesv2";

export function makeSes(region) {
  return new SESv2Client({ region });
}

`app/src/services/email/email-service.js`

import { SendEmailCommand } from "@aws-sdk/client-sesv2";

function subject() {
  return "Confirme seu e-mail";
}

function htmlBody(link, token) {
  return link
    ? `<p>Obrigado por se cadastrar.</p><p>Clique para verificar: <a href="${link}">${link}</a></p><p>Ou use este token: <b>${token}</b></p>`
    : `<p>Obrigado por se cadastrar.</p><p>Use este token para verificar: <b>${token}</b></p>`;
}

function textBody(link, token) {
  return link
    ? `Obrigado por se cadastrar.\nVerifique seu e-mail: ${link}\nToken: ${token}`
    : `Obrigado por se cadastrar.\nToken de verificação: ${token}`;
}

export async function sendVerificationEmail({ ses, sender, to, link, token }) {
  const input = {
    FromEmailAddress: sender,
    Destination: { ToAddresses: [to] },
    Content: {
      Simple: {
        Subject: { Data: subject() },
        Body: {
          Html: { Data: htmlBody(link, token) },
          Text: { Data: textBody(link, token) }
        }
      }
    }
  };
  await ses.send(new SendEmailCommand(input));
}

`app/src/services/store/repository.js`

import { DynamoDBClient } from "@aws-sdk/client-dynamodb";
import { DynamoDBDocumentClient, PutCommand, GetCommand, UpdateCommand } from "@aws-sdk/lib-dynamodb";

export function makeRepo(tableName) {
  const ddb = new DynamoDBClient({});
  const doc = DynamoDBDocumentClient.from(ddb);
  return {
    async putPending({ email, token, expiresAt }) {
      const item = { pk: email, sk: token, status: "pending", expiresAt };
      await doc.send(new PutCommand({ TableName: tableName, Item: item, ConditionExpression: "attribute_not_exists(pk) AND attribute_not_exists(sk)" }));
      return item;
    },
    async getOne({ email, token }) {
      const res = await doc.send(new GetCommand({ TableName: tableName, Key: { pk: email, sk: token } }));
      return res.Item || null;
    },
    async markVerified({ email, token }) {
      await doc.send(new UpdateCommand({
        TableName: tableName,
        Key: { pk: email, sk: token },
        UpdateExpression: "SET #s = :v",
        ExpressionAttributeNames: { "#s": "status" },
        ExpressionAttributeValues: { ":v": "verified" }
      }));
    }
  };
}

`app/src/usecases/send-verification.js`

import { generateToken, expirationEpoch } from "../services/token/token-service.js";

export async function sendVerification({ repo, emailService, email, baseUrl, ttlSeconds, sender }) {
  const token = generateToken();
  const expiresAt = expirationEpoch(ttlSeconds);
  await repo.putPending({ email, token, expiresAt });

  const link = baseUrl ? `${baseUrl.replace(/\/$/, "")}/verify?email=${encodeURIComponent(email)}&token=${encodeURIComponent(token)}` : "";
  await emailService.send({ to: email, token, link, sender });
  return { email, expiresAt, linkPresent: Boolean(link) };
}

`app/src/usecases/verify-token.js`

export async function verifyToken({ repo, email, token }) {
  const item = await repo.getOne({ email, token });
  if (!item) return { ok: false, reason: "invalid" };
  if (item.expiresAt && item.expiresAt < Math.floor(Date.now() / 1000)) return { ok: false, reason: "expired" };
  await repo.markVerified({ email, token });
  return { ok: true };
}

`app/src/handler.js`

import { env } from "./core/env.js";
import { makeRepo } from "./services/store/repository.js";
import { makeSes } from "./services/email/email-client.js";
import * as emailSvc from "./services/email/email-service.js";
import { sendVerification } from "./usecases/send-verification.js";
import { verifyToken } from "./usecases/verify-token.js";

const repo = makeRepo(env.tableName);
const ses = makeSes(process.env.AWS_REGION);

const emailService = {
  send: ({ to, token, link, sender }) => emailSvc.sendVerificationEmail({ ses, sender: sender || env.sender, to, link, token })
};

function json(status, body, headers = {}) {
  return { statusCode: status, headers: { "content-type": "application/json", ...headers }, body: JSON.stringify(body) };
}

export async function handler(event) {
  const rawPath = event.rawPath || "/";
  const method = event.requestContext?.http?.method || "GET";

  if (method === "POST" && rawPath.endsWith("/send")) {
    const body = typeof event.body === "string" ? JSON.parse(event.body || "{}") : event.body || {};
    if (!body?.email) return json(400, { error: "email_required" });

    const result = await sendVerification({
      repo,
      emailService,
      email: body.email,
      baseUrl: env.verifyBaseUrl,
      ttlSeconds: env.tokenTtlSeconds,
      sender: env.sender
    });
    return json(202, { email: result.email, expiresAt: result.expiresAt, linkIncluded: result.linkPresent });
  }

  if (method === "GET" && rawPath.endsWith("/verify")) {
    const qs = event.rawQueryString || "";
    const params = Object.fromEntries(new URLSearchParams(qs).entries());
    const email = params.email || "";
    const token = params.token || "";
    if (!email || !token) return json(400, { error: "email_and_token_required" });

    const res = await verifyToken({ repo, email, token });
    if (!res.ok) return json(400, { verified: false, reason: res.reason });
    return json(200, { verified: true });
  }

  return json(404, { error: "not_found" });
}

Build do artefato da Lambda

`app/build.sh`

#!/usr/bin/env bash
set -euo pipefail
cd "$(dirname "$0")"
npm ci
cd ..
rm -f function.zip
cd app
zip -r ../function.zip . -x "*.zip"

Esse zip contém src/ e node_modules. O handler é handler.handler como configurado.

Deploy: passo a passo

Ajuste variáveis:

Crie um arquivo infra/terraform.tfvars:

aws_region         = "us-east-1"
project_name       = "email-verify"
environment        = "dev"
sender_email       = "seu-remetente@dominio.com"
lambda_artifact_path = "../function.zip"
token_ttl_seconds  = 900
verify_base_url    = "" # deixe vazio por agora, ou coloque a URL que fará o GET /verify

Verifique/prepare o remetente no SES (console) ou com Terraform do módulo ses. Se a conta estiver em sandbox, verifique também o destinatário de teste.
Gere o pacote da Lambda:

bash app/build.sh

Aplique Terraform:

cd infra
terraform init
terraform apply -auto-approve

Copie a Function URL de saída.

Se quiser que o e-mail traga o link direto de verificação apontando para a própria Lambda, defina verify_base_url igual à Function URL e rode:

terraform apply -var="verify_base_url=$(terraform output -raw function_url)" -auto-approve

Como testar (curl, Postman e AWS CLI)

1) Disparar e-mail de verificação

FUNCTION_URL=$(terraform -chdir=infra output -raw function_url)
curl -s -X POST "$FUNCTION_URL/send" \
  -H "content-type: application/json" \
  -d '{"email":"destinatario@exemplo.com"}' | jq

Resposta esperada:

{
  "email": "destinatario@exemplo.com",
  "expiresAt": 1724099999,
  "linkIncluded": true
}

Se verify_base_url estiver vazio, linkIncluded será false e o corpo do e-mail trará apenas o token.

O envio usa a operação SESv2 SendEmail do SDK v3.

2) Validar o token

Pegue o link no e-mail (se configurado) ou recupere o token no próprio e-mail. Então:

curl -s "$FUNCTION_URL/verify?email=destinatario@exemplo.com&token=SEU_TOKEN" | jq

Resposta esperada em sucesso:

{ "verified": true }

Falhas retornam HTTP 400 com reason igual a invalid ou expired.

3) Conferir no DynamoDB com AWS CLI

aws dynamodb get-item \
  --table-name $(terraform -chdir=infra output -raw table_name) \
  --key '{"pk":{"S":"destinatario@exemplo.com"}, "sk":{"S":"SEU_TOKEN"}}'

Você vai ver status mudando para verified. Se estiver aguardando expiração, lembre que o TTL é assíncrono; a remoção pode levar algum tempo.

Custos, limites e produção

DynamoDB com PAY_PER_REQUEST e TTL tem custo muito baixo no cenário de verificação.
Lambda é cobrada por invocação e tempo de execução, tipicamente centavos.
SES em sandbox limita destinatários e throughput; para produção, solicite saída de sandbox.
Para domínios próprios, prefira identidade de domínio e configure DKIM/SPF; aqui usei identidade por e-mail para simplificar o início.

Próximos passos

Substituir a Function URL por API Gateway com authorizers.
Adicionar template HTML rico e Configuration Set do SES (monitoramento, IP pool gerenciado).
Colocar a verificação atrás de um domínio customizado e TLS, com CloudFront + Function URL ou API Gateway.

Com isso, você tem um pipeline completo de verificação de e-mail, IaC de ponta a ponta e uma Lambda enxuta pronta para conectar ao seu front-end.

💡Curtiu?

Se quiser trocar ideia sobre IA, cloud e arquitetura, me segue nas redes:

Publico conteúdos técnicos direto do campo de batalha. E quando descubro uma ferramenta que economiza tempo e resolve bem, como essa, você fica sabendo também.

Referências

Daniel, G. (2025, August 9). AWS SES with a NestJS Backend to Send Email Verifications. DEV Community. https://dev.to/aws-builders/aws-ses-with-a-nestjs-backend-to-send-email-verifications-2l9h (DEV Community)

Amazon Web Services. (n.d.). Request production access (Moving out of the Amazon SES sandbox). In Amazon Simple Email Service Developer Guide. https://docs.aws.amazon.com/ses/latest/dg/request-production-access.html (AWS Documentation)

Amazon Web Services. (n.d.). Verified identities in Amazon SES. In Amazon Simple Email Service Developer Guide. https://docs.aws.amazon.com/ses/latest/dg/verify-addresses-and-domains.html (AWS Documentation)

Amazon Web Services. (n.d.). Using time to live (TTL) in DynamoDB. In Amazon DynamoDB Developer Guide. https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/TTL.html (AWS Documentation)

HashiCorp. (n.d.). aws_lambda_function_url (Resource). Terraform Registry. https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/lambda_function_url.html (Terraform Registry)

Amazon Web Services. (n.d.). Creating and managing Lambda function URLs. In AWS Lambda Developer Guide. https://docs.aws.amazon.com/lambda/latest/dg/urls-configuration.html (AWS Documentation)

Amazon Web Services. (n.d.). SendEmailCommand (SESv2). In AWS SDK for JavaScript v3 API Reference. https://docs.aws.amazon.com/goto/SdkForJavaScriptV3/sesv2-2019-09-27/SendEmail (AWS Documentation)

Amazon Web Services. (n.d.). SESv2Client. In AWS SDK for JavaScript v3. https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/client/sesv2 (AWS Documentation)

Microsoft lança cursos Gratuitos sobre IA Generativa Para iniciantes e para desenvolvedores JavaScript

Cláudio Filipe Lima Rapôso — Sat, 09 Aug 2025 01:06:30 +0000

Neste artigo comparo dois cursos gratuitos da Microsoft, AI Agents for Beginners e Generative AI for Beginners with JavaScript. Eu os explorei a fundo porque queria compreender como cada um apresenta conceitos modernos de inteligência artificial para quem está começando. Descobri que o primeiro foca na criação de agentes controlados por modelos de linguagem, enquanto o segundo introduz IA generativa usando JavaScript.

AI Agents for Beginners

Estrutura e conteúdos

O curso possui 11 lições independentes, cada uma com texto, vídeo curto e exemplos de código em Python. As lições vão desde conceitos básicos de agentes e padrões de projeto até o uso de retrieval augmented generation (RAG), design multifuncional e implantação. O conteúdo é traduzido automaticamente para vários idiomas, incluindo português.

Conteúdo técnico

O curso define agente de IA como um sistema com ambiente, sensores, atuadores, memória e ferramentas, permitindo que um modelo de linguagem execute ações. Aborda tipos como reflexo simples, baseado em modelo, orientado a metas e utilitário. Há comparação entre AutoGen, Semantic Kernel e Azure AI Agent Service.

Pontos fortes

Foco claro em design de agentes
Integração com ferramentas Microsoft (Azure, Semantic Kernel, AutoGen)
Material multimídia e multilingue

Generative AI for Beginners with JavaScript

Estrutura e proposta

O curso tem narrativa gamificada: o aluno viaja no tempo e interage com figuras históricas. São 8 lições sobre IA generativa, desde conceitos de LLMs até engenharia de prompts e RAG. Inclui quizzes e exercícios práticos, com código em JavaScript executável no GitHub Codespaces.

Conteúdo técnico

A primeira lição apresenta fundamentos de IA generativa, exemplos de aplicação e um exemplo de endpoint de chat usando a API gpt-4o-mini do GitHub Models. As lições seguintes exploram engenharia de prompts, RAG e MCP.

Pontos fortes

Narrativa envolvente
Foco em JavaScript e desenvolvimento web
Exercícios práticos e quizzes
Uso de modelos gratuitos no GitHub Models

Comparação e recomendações

Na minha visão, AI Agents for Beginners é ideal para quem quer mergulhar na arquitetura de agentes e já possui alguma experiência técnica, especialmente em Python e Azure. Já Generative AI for Beginners with JavaScript é mais indicado para iniciantes no desenvolvimento web que desejam aplicar IA generativa de forma prática e divertida.

Se o objetivo é trabalhar com automação complexa e integração de múltiplos agentes, recomendo o primeiro. Se a meta é prototipar aplicações de IA generativa em JavaScript de forma rápida, o segundo curso é o caminho.

Referências

Microsoft. (2025a). AI Agents for Beginners – A Course. GitHub Pages. Recuperado em 8 de agosto de 2025, de https://microsoft.github.io/ai-agents-for-beginners/
Microsoft. (2025b). Generative AI for Beginners with JavaScript. GitHub Pages. Recuperado em 8 de agosto de 2025, de https://microsoft.github.io/generative-ai-with-javascript/#/
Microsoft Corporation. (2025a). Introduction to AI Agents and Agent Use Cases. Recuperado em 8 de agosto de 2025, de https://microsoft.github.io/ai-agents-for-beginners/01-intro-to-ai-agents/
Microsoft Corporation. (2025b). Intro to Generative AI. Recuperado em 8 de agosto de 2025, de https://github.com/microsoft/generative-ai-with-javascript

Forem: Cláudio Filipe Lima Rapôso

Road to Golden Jacket: My Journey and Tips for the New AWS SOA-C03 Exam 🚀

📈 The CloudWatch Marathon

🔄 Bridging the Gap: SysOps to CloudOps

💡 My Top Tips for Exam Day

💡 Enjoyed it?

From Infrastructure to Product: Pipelines into a Profitable SaaS

🏗️ 1. The Reference Architecture on AWS

Core Components:

⚙️ 2. The "Zero-Touch" Provisioning Engine

🌍 Level 1: The System Context Diagram (Business View)

Level 2: The Container Diagram (Solution/Cloud View)

🧩 Level 3: The Component Diagram (Engineering/Code View)

🌍 3. Global Scaling and Data Compliance

💎 4. Tiered Product Strategy (FinOps)

Tier 1: High School & Small College Plan (High Volume)

Tier 2: University & Research Institute Plan (High Margin)

🐳 5. Dockerizing OJS

🛠️ 6. Infrastructure as Code (Terraform)

Variable Injection (FinOps)

🚀 7. CI/CD with GitHub Actions

💰 8. FinOps: Cost Optimization on AWS

🎯 Conclusion

Reason Your Python Code is Hard to Test with Single Responsibility Principle, And How to Fix It! (Portuguese version)

❌ O "Antes": A Violação do SRP

✅ A Refatoração: Separação de Preocupações

1. A Entidade (Estrutura de Dados)

2. O Validador (Regras de Negócio)

3. O Repositório (Persistência)

4. O Serviço (O Orquestrador)

Exemplo de Uso

Conclusão

Bot de Monitoramento para SushiSwap V3 em Go — Parte 1

Conceito e fluxo

Preparação do ambiente

Configuração com .env

Implementação do código

config.go

database.go

prices.go

main.go

Execução

Encerramento

Referências

💡Curtiu?

Autenticação Segura com Microsoft Entra ID para desenvolvedores Typescript

Arquitetura Geral

1. Configuração no Entra ID

2. Frontend Next.js com NextAuth

Instalação

Variáveis de ambiente

Configuração do NextAuth

Componente de Login/Logout (AuthButton.tsx)

Tela Principal (page.tsx)

3. Server Component: Página Protegida

4. Backend Node/TypeScript

Dependências

Código (src/index.ts)

Boas Práticas

Conclusão

Referências

Criando um Sidecar em Go para acessar o Microsoft Graph via gRPC

1. O que é um Sidecar?

2. Arquitetura

3. Definindo o contrato gRPC

Explicando

Gerando código Go

4. Implementando o sidecar em Go

4.1 Estrutura base

4.2 Gerenciamento de Token

Explicando

4.3 Implementando GetUser

Explicando

4.4 Subindo o servidor gRPC

Explicando

5. Executando

6. Exemplo de resposta

7. Por que usar Sidecar?

Conclusão

💡Curtiu?

Configuração com `.env`

`config.go`

`database.go`

`prices.go`

`main.go`

Componente de Login/Logout (`AuthButton.tsx`)

Tela Principal (`page.tsx`)

Código (`src/index.ts`)

4.3 Implementando `GetUser`

`go.mod`

`internal/types/messages.go`

`internal/messaging/rabbitmq.go`

`cmd/marketdata/main.go`

`cmd/orchestrator/main.go`

`cmd/order/main.go`

`internal/tracing/otel.go` (exemplo mínimo)

`.env.example`

`docker-compose.yml`

1) Root: `infra/main.tf`

2) Root: `infra/variables.tf`

3) Root: `infra/outputs.tf`

Módulo SES: `infra/modules/ses/main.tf`

Módulo DynamoDB: `infra/modules/dynamodb/main.tf`

Módulo IAM: `infra/modules/iam/main.tf`

Módulo Lambda: `infra/modules/lambda/main.tf`

`app/package.json`

`app/src/core/env.js`

`app/src/domain/types.js`

`app/src/services/token/token-service.js`

`app/src/services/email/email-client.js`

`app/src/services/email/email-service.js`

`app/src/services/store/repository.js`

`app/src/usecases/send-verification.js`

`app/src/usecases/verify-token.js`

`app/src/handler.js`

`app/build.sh`