DEV Community: Marcelo Magario

Another E2E Solution delivered. This time with CI/CD, AWS EventBridge and ECS Fargate

Marcelo Magario — Tue, 10 Mar 2026 01:17:40 +0000

I recently completed a personal project focused on automating a password rotation process for a third-party system.

This integration requires authentication, but the system enforces a monthly password rotation. When the password expires, uploads and downloads start failing, which quickly turns into a operational issue.

To remove the need for manual updates and the risk of someone simply forgetting, I built an automation to handle this end to end.

The solution is a Python worker using Selenium with headless Chromium, executed on a schedule and backed by a full CI/CD pipeline. On every push to the main branch, GitHub Actions assumes an AWS IAM Role via OIDC, builds the Docker image, and pushes it to Amazon ECR. The workflow then registers a new ECS Task Definition revision, updating only the container image.

This is the Architecture design solution:

CI/CD:

Execution is handled by Amazon EventBridge, which triggers the task every 29 days:

ECS Cluster:

The task runs on ECS Fargate in a public subnet, with a public IP and outbound traffic allowed. When triggered, Fargate starts the container, runs automation.py, launches Selenium with Chromium and Chromedriver, logs into the system, performs the password rotation, and exits. On success, the task finishes automatically with exit code 0. If an exception occurs, logs are sent to CloudWatch and the error is reported to a Slack alerts channel.

Archtecture decisions:

Using ECS Fargate instead of Lambda was a deliberate decision. Running Selenium with Chromium on Lambda usually requires custom layers and fine-tuning, and it’s easy to hit limits around memory, package size, or execution time. With Fargate, the entire environment is packaged in the Docker image, with predictable runtime behavior and flexible CPU and memory allocation, which makes this kind of workload much easier to operate.

In the end, this is a simple batch worker. It runs on a schedule, does one job, and exits. For headless browser automation, this approach turned out to be more straightforward and reliable.

Hotfix Story: Fixing Password Reset Under Pressure

Marcelo Magario — Thu, 21 Aug 2025 11:58:45 +0000

Sometimes in software development, business priorities demand immediate action. That was the case recently when our password reset flow started failing for users, while at the same time we received feedback that the recovery emails were unclear and hard to identify. Our development environment was full of ongoing changes, so the safest path was to deliver a focused hotfix straight to production.

I saw in the AWS (ECS Logs) were logs telling that the app was crashed with ReferenceError of Redis.

The Challenges

Two main problems had to be solved:

Email recovery template – Investors reported that password recovery emails were in English only and didn’t include any reference to the company. This made them hard to find and often overlooked. The fix required introducing support for multiple languages, defaulting to English when no language was provided, and including the company name in the email subject.

Redis v4 migration issues – At the same time, our password reset functionality was broken due to a Redis upgrade. Moving to Redis v4 exposed a scoping issue: the Redis client wasn’t being referenced properly, causing ReferenceError: Client not found and crashing our app in ECS logs. Tokens couldn’t be set or validated, which meant the password reset flow completely failed. Fixing this required revisiting the Redis initialization, ensuring proper connection handling, and maintaining compatibility with parts of the codebase still expecting the legacy behavior.

Overcoming the Issues

The hotfix involved:

Creating a new email template in Portuguese, with dynamic company branding in the subject line. To bring the Company's name into the email subject, I had to send a company UUID to another system and then receive the company name.

Adding support for a language parameter in requests, with a fallback to English if none was provided.

Refactoring Redis initialization to ensure the client was accessible across the app.

Adjusting for Redis v4 changes while keeping legacy expectations working until the rest of the system could be migrated.

Business Impact

These fixes had direct and immediate value:

Clearer communication: Password recovery emails now include the company name and are localized, reducing confusion for end users.

Restored critical functionality: Users can once again reset their passwords without encountering errors, eliminating support tickets and frustration.

Stability under change: Despite ongoing development work, the hotfix restored confidence that critical user flows remain reliable.

These changes turned a broken, confusing experience into a smooth, branded, and functional process. It was a reminder that sometimes the fastest path to protecting user trust is a focused hotfix, even when the technical challenges involve version upgrades and tricky scope bugs.

Improving Upload Performance: Why I Chose Node.js Over Python

Marcelo Magario — Fri, 01 Aug 2025 23:34:14 +0000

Handling large file (20GB +) can be tough. I'm studying a way to improve performance on our file manager system when uploading a large files. The initial idea is to create a PoC to check performance between Node.JS and Python workers.

Our feature users will paste a Google Drive link, and in the background, the system downloads the file and uploads it to AWS S3 — all without blocking the user.

What the System Does

User pastes a Google Drive link
The system adds a job to a queue
A background worker downloads the file
The file is uploaded to AWS S3
The user gets notified when it’s done

Main Goals

Handle big files (20GB+)
Use low memory (no saving to disk)
Be fast and reliable

Python vs Node.js
I tested both. Python (with FastAPI and boto3) works, but streaming big files needs extra care for what I've seen in my researches.

Node.js is built for streaming. Using stream, fs, and @aws-sdk/client-s3, I could pipe the file directly from Google Drive to S3. No buffer, no saving to disk, and memory stays low.

Why I Picked Node.js

Streams are native and simple
Uses less memory
It seems to be more stable for this kind of task

For moving large files from cloud to cloud, Node.js seems to be a better and more efficient choice.

I’ll post the solution soon once is done!

The RabbitMQ queue got stuck - How I solve this bug

Marcelo Magario — Thu, 17 Jul 2025 17:38:28 +0000

Recently I faced a problem at work: our mailing system stopped working and a heap of emails weren’t being sent. When we looked at RabbitMQ:

There was one “Unacked” message stuck on the consumer, and lots of “Ready” messages were piling up.

After investigating, we found that our mailer supplier’s API broke because the mailing payload was over 30 MB. Digging deeper, we saw that one user had sent a mailing with a 70 MB attachment.

First, I tried adding attachment-file-size validation and overall payload-size validation (body + attachments) on our backend. But the problem was that the user only saw “the file is too large” once they tried to save or send the mailing. So, after analyzing our process, I ended up putting validation in both the frontend and backend.

Frontend:

Validating the attachment size on the frontend lets the user know immediately if the file is too large:

const handleAttachment = () => {
  if (selectedFiles && selectedFiles[0]) {
    const sizeInMB = selectedFiles[0].size / (1024 * 1024)
    if (sizeInMB > 9) {
      setShowSizeError(true)
      return
    }
  }
  closeModal()
}

Backend

To make sure our mailer supplier’s API won’t break again, I added payload validation on our backend. It calculates the size of all attachments plus the email content, then checks whether the total size exceeds our limit:

// helper/requestSize.js
module.exports.computeRequestSize = (request) => {
  let totalSize = 0
  let bodyBytes = 0
  let attachmentsBytes = 0

  if (request.body) {
    const serialized = JSON.stringify(request.body)
    bodyBytes = Buffer.byteLength(serialized, 'utf8')
    totalSize += bodyBytes
  }

  if (request.files) {
    Object.values(request.files).forEach(file => {
      attachmentsBytes += file.size
    })
    totalSize += attachmentsBytes
  }

  return totalSize
}

and on the endpoint:

const payloadSize = util.computeRequestSize(request)
if (payloadSize > CONFIG.MAX_REQUEST_SIZE) {
  response.sendError400(CONFIG.ERROR_PAYLOAD_TOO_LARGE)
  return next()
}

For safety reasons I always change a little bit my code before post here.

Now we know this won’t happen again.
What would you do?

New project deployed on AWS! Wi-Fi Connectivity Notification!

Marcelo Magario — Wed, 09 Jul 2025 23:15:46 +0000

So, as usually the project starts to solve a problem this one is not different either.

The problem

My family has a beach house, and very often we go there and once we arrive we find out that the internet is not working! so annoying! That is really bad because sometimes we have plenty of work to do and we can't do much. So frustrating going there and wasting the afternoon calling and waiting the technician resolution.

So I decided to solve it for good!
I was thinking: what if we could know if the internet is working (or not) before we arrive there? even better, what if we could be notified if the internet was down or restored? well, that's when it all started the idea.

The solution
I took my brother's really old Galaxy A5 (2016) falling apart lol. It was just sitting in a drawer, and turned it into a simple internet monitor. Every 6 hours, it sends a quick GET request to a /heartbeat endpoint I created on a Node.js backend. This cycle can be configurated on .env to better attend your needs.

The backend is deployed on an AWS EC2 instance and already running in production.

If that heartbeat stops coming, the backend notices and sends me an email using AWS SES. When the connection comes back, I get another email letting me know it's back online.

The Stack

Galaxy A5 (2016): Sends a simple GET request every 6 hours. To send the requests I'm using the Macrodroid.

AWS EC2 (Node.js): Stores the last ping timestamp and checks for missed heartbeats

AWS SES: Sends email alerts if the device goes silent or comes back

Here's what the archtecture looks like:

It’s deployed, running, and giving me peace of mind!

Have a look on the code...

Github REPO:
https://github.com/marcelomagario/wifi-check

Difficulties & Learnings:
AWS SES Region: I learned that email verification is region-specific. My EC2 was in Ohio (us-east-2), but my SES was in N. Virginia (us-east-1). I had to verify my email in the correct region to make it work.
Email Verification: SES requires all sender and (in sandbox mode) recipient emails to be verified. This step is easy to miss!
Spam Issues: Emails sent from SES using a Gmail address as the sender often end up in spam. Using a custom domain is the best way to improve deliverability (but I didn't do because I didn't want to pay! cheap bastard! heheh).
Cost: By using a t2.micro EC2 instance and SES Free Tier, I can run this project 24/7 at almost zero cost.

... from now on, English only!

Marcelo Magario — Wed, 09 Jul 2025 22:44:43 +0000

Hey guys,

I decided that from now on I will sticky to English only on my posts.

That way I might be able to achieve a bigger number of devs around the globe and not only in portuguese speakers country, right?

Furthermore, I will try to avoid to get help from any IA or translation services because I also want to measure my english grammar skills. So, sorry in advanced for my grammar mistakes heheh!

Conteinerizei o meu projeto full-stack com o Docker/Docker compose

Marcelo Magario — Mon, 09 Jun 2025 21:16:21 +0000

Fala pessoal! lembra do meu projeto portfólio que estou desenvolvendo?

https://github.com/marcelomagario/portfolio

Hoje resolvi conteinerizar ele utilizando o Docker e orquestrando com o Docker Compose.

separei em 2 containes diferentes:

Frontend (React/Vite)
Backend (Node.js/TypeScript)

e configurei da seguinte maneira:

Frontend:

Dockerfile

FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
EXPOSE 5173
ENV HOST=0.0.0.0
ENV PORT=5173
CMD ["npm", "run", "dev"]

Backend:

Dockerfile

FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
EXPOSE 3001
CMD ["npx", "ts-node", "src/app.ts"]

E na orquestração, fiz da seguinte maneira para que o frontend dependa do backend:

docker-compose.yml

version: '3.8'

services:
  frontend:
    build: 
      context: ./frontend
      dockerfile: Dockerfile
    ports:
      - "5173:5173"
    volumes:
      - ./frontend:/app
      - /app/node_modules
    environment:
      - NODE_ENV=development
    depends_on:
      - backend

  backend:
    build:
      context: ./backend
      dockerfile: Dockerfile
    ports:
      - "3001:3001"
    volumes:
      - ./backend:/app
      - /app/node_modules
    environment:
      - NODE_ENV=development
    env_file:
      - ./backend/.env
    depends_on:
      - postgres

  postgres:
    image: postgres:16-alpine
    ports:
      - "5434:5432"
    environment:
      POSTGRES_USER: ${POSTGRES_USER}
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
      POSTGRES_DB: ${POSTGRES_DB}
    volumes:
      - postgres_data:/var/lib/postgresql/data
      - ./postgres-init:/docker-entrypoint-initdb.d

Agora para rodar o meu projeto é só rodar o docker-compose up. Ficou mais fácil de configurar e o ambiente mais consistente!

Como provisionei meu BD PostgreSQL no AWS RDS

Marcelo Magario — Mon, 09 Jun 2025 00:22:15 +0000

Provisionei meu primeiro banco de dados PostgreSQL gerenciado na AWS usando o serviço RDS (Relational Database Service).

Antes de começar, pesquisei sobre os benefícios do AWS RDS e instantaneamente percebi que em vez de eu mesmo instalar, configurar e manter o PostgreSQL em um servidor (EC2), a AWS faria esse trabalho por mim. Além disso, ainda com benefícios de atualizações de versão, patches de segurança, backups automáticos, escalabilidade e monitoramento etc.

Como Criei o Banco de Dados

O processo no Console da AWS foi bem intuitivo. Mas como estou focando no aprendizado e evitar gastos desnecessários, utilizei a opção de "Free Tier" para garantir que não teria custos neste meu ambiente de desenvolvimento.

Credenciais: Defini um DB instance identifier (o nome do meu servidor, que chamei de portfolio-db-instance) e as credenciais de acesso (usuário e senha master). O RDS usou essas informações para criar o usuário principal do banco.

Conectividade: Este foi o ponto mais crítico da configuração!

Public Access: Para conseguir me conectar da minha máquina local, marquei a opção "Public access" como "Yes". Aprendi que em um ambiente de produção, isso é uma má prática de segurança, onde o ideal é manter o banco em uma sub-rede privada, ou seja, só acessado de dentro da AWS.

VPC Security Group: Este era o firewall virtual da minha instância. Criei um novo grupo (portfolio-db-sg) que, por padrão, bloqueava todo o tráfego de entrada.

Após a criação, o RDS me forneceu um Endpoint. Este passou a ser o host do meu banco de dados, um endereço único no formato nome-da-instancia.xxxxxxxxxxxx.regiao.rds.amazonaws.com.

Como Configurei o Acesso 🛡️

Por padrão, mesmo com o acesso público habilitado, descobri que o firewall (Security Group) ainda impedia minha conexão. Para resolver, precisei criar uma regra de liberação.

Naveguei até a configuração do Security Group associado à minha instância RDS.
Adicionei uma Inbound Rule (Regra de Entrada).
Configurei a regra da seguinte forma: Type: PostgreSQL (que já preencheu a porta 5432). Source: My IP (a AWS detectou e preencheu meu IP público). Essa regra declarou para o firewall só permitir conexões na porta 5432 vindas somente do meu endereço de IP.

Agora que está rodando, vou fuçar mais o CloudWatch e RDS Performance Insights.

Minha implementação de Autenticação com JWT e Bcrypt

Marcelo Magario — Sat, 07 Jun 2025 21:19:26 +0000

Eai devs!

Neste post, vou detalhar o passo a passo de como de como implementei a autenticação stateless usando Node.js com TypeScript, Express, PostgreSQL, e a dupla bcryptjs para hashing de senhas e JSON Web Tokens (JWT) para gerenciamento de sessão no meu projeto pessoal.

A Estrutura do Projeto

Para manter o código organizado, dividi a lógica em três partes principais:

1. authRoutes.ts: Define os endpoints /register e /login. Sua única responsabilidade é direcionar as requisições para o controller correto.

2. authController.ts: Contém a regra de negócio. É aqui que validamos os dados, interagimos com o banco e decidimos qual resposta enviar.

3. utils/auth.ts (Abstrato): Funções complementares para hashear senhas e gerar tokens, para não repetirmos código. Achei que ficou mais organizado desse jeito.

Passo 1: Registro do Usuário e Hashing da Senha

Nunca devemos salvar senhas em texto puro no banco de dados. A primeira etapa é garantir que a senha do usuário seja transformada em um hash irreversível. Para isso, usamos o bcryptjs.

O controller authController.ts cuida desse processo na função registerUser:

import bcrypt from 'bcryptjs';

// Função conceitual que criei para hashear uma senha
async function criarHashSenha(senha: string): Promise<string> {
    // O 'salt' adicionou uma camada extra de segurança ao hash
    const salt = await bcrypt.genSalt(10);
    const hash = await bcrypt.hash(senha, salt);
    return hash;
}

// Como eu usei:
// const hashDaSenha = await criarHashSenha(senhaDoUsuario);
// E então, salvei o `hashDaSenha` no meu banco de dados.

A função hashPassword em utils/auth.ts seria algo simples como:

// utils/auth.ts
import bcrypt from 'bcryptjs';

export const hashPassword = async (password: string): Promise<string> => {
    const salt = await bcrypt.genSalt(10); // Gera um "sal" para fortalecer o hash
    return await bcrypt.hash(password, salt);
};

Passo 2: gerando token de acesso do JWT

Após validar a senha no login com bcrypt.compare(), o passo seguinte que implementei foi gerar o token. Um ponto de atenção que tive foi nunca deixar a chave secreta no código.

import jwt from 'jsonwebtoken';

// Função conceitual que usei para gerar um token
function gerarToken(idDoUsuario: string): string {

    // 🔑 A chave secreta busquei das minhas variáveis de ambiente!
    const chaveSecreta = process.env.JWT_SECRET;

    if (!chaveSecreta) {
        throw new Error('Chave secreta do JWT não definida!');
    }

    const payload = { id: idDoUsuario };

    // Assinei o token com a chave e defini um tempo de expiração
    return jwt.sign(payload, chaveSecreta, {
        expiresIn: '1h' // Token expira em 1 hora
    });
}

Passo 3: Middleware de proteção

Este foi o guardião que implementei para as minhas rotas. Neste exemplo, foquei apenas na lógica de verificação do token, que foi o coração do processo.

// Middleware conceitual que criei para proteger as rotas
function protegerRota(req: Request, res: Response, next: NextFunction) {
    const authHeader = req.headers.authorization;

    if (!authHeader || !authHeader.startsWith('Bearer ')) {
        // Neguei o acesso se o token não foi fornecido
        return res.status(401).json({ message: 'Acesso negado: token não fornecido.' });
    }

    try {
        const token = authHeader.split(' ')[1];
        const chaveSecreta = process.env.JWT_SECRET as string;

        // jwt.verify() validou o token. Se fosse inválido, dispararia um erro.
        const payloadVerificado = jwt.verify(token, chaveSecreta);

        next(); // Token válido, liberei o acesso!
    } catch (error) {
        // Neguei o acesso se o token era inválido
        return res.status(401).json({ message: 'Token inválido ou expirado.' });
    }
}

O que acharam? vocês fariam diferente?

Como resolvi a vulnerabilidade de SQL Injection hoje...

Marcelo Magario — Mon, 02 Jun 2025 16:16:59 +0000

E aí, devs! Hoje precisava solucionar alguns pontos de vulnerabilidade de SQL injection de um resultado de pentest. O teste fazia uma simulação de alterar o payload da request e colocava um HTML e um script no meio desses dados e alterar todo o e-mail que ia ser disparado.

Mudava toda a conversa original do e-mail.
Escondia as partes que realmente importavam.
colocava uns links fakes para phishing, fazendo parecer que são os links de verdade.

Para solucionar isso fiz um middleware em Node.js no nosso projeto para validar e sanitizar todos os dados no backend antes de serem usados:

1. Pega os Dados da Requisição: Primeiro, ele pega os dados que vieram na bagagem da requisição web, especificamente do corpo body dela. É dali que ele espera tirar informações como um pacote de dados do usuário userInputPayload, uma dica para o assunto do e-mail emailSubjectHint, o link principal mainLink e o link da imagem da marca brandImageUrl.
2. Verificação Essencial: Ele confere se o userInputPayload (que é onde devem estar os detalhes do cliente como nome, e-mail, empresa, telefone, categoria de perfil e a origem do dado) realmente veio e se é um objeto válido. Se não, já corta o mal pela raiz e avisa que tá faltando coisa.
3. Prepara as Ferramentas de Checagem (Regex): O "segurança" usa algumas expressões regulares para poder inspecionar os dados:

Uma regex é especialista em farejar caracteres perigosos (tipo <, >, /, ', ", ;, =), aqueles que são a porta de entrada pra HTML injection.
Outra regex é focada em garantir que o formato do e-mail (clientEmail) esteja correto.
E uma terceira cuida de verificar se as URLs fornecidas para o mainLink e brandImageUrl seguem o padrão esperado (com protocolo, domínio, etc.).
Inspeção Campo a Campo: Com as ferramentas em mãos, ele passa um pente fino em cada informação:
Dados como nome do cliente (clientName), organização (clientOrg), categoria de perfil (profileCategory), tag de origem do dado (dataSourceTag) e telefone (clientPhone) são checados contra a regex de caracteres perigosos.
O e-mail do cliente (clientEmail) tem seu formato validado pela regex específica para e-mails.
Os campos emailSubjectHint, mainLink e brandImageUrl são opcionais. Se eles não vierem, tudo bem. Mas se vierem, também passam pela checagem: emailSubjectHint contra caracteres perigosos, e mainLink e brandImageUrl contra a regex de URLs.

4. Decisão Final:

Algo errado? Bloqueia! Se qualquer um desses campos não passar na inspeção, o "segurança" impede a continuação do processo. Ele manda uma resposta de erro (um 400 Bad Request), avisando que os dados estão inválidos ou contêm caracteres não permitidos. Isso evita que dados "contaminados" sigam adiante.
Tudo certinho? Pode passar! Se todos os dados estiverem limpinhos e válidos, o "segurança" dá sinal verde, e a requisição continua seu fluxo normal para o próximo passo, que seria, por exemplo, a lógica de montar e enviar o e-mail.
Essa abordagem ajuda a garantir que apenas dados seguros e bem formatados sejam usados, diminuindo drasticamente o risco de injeções de HTML.

Criando o meu Projeto de Portfólio pessoal com Deploy na AWS!

Marcelo Magario — Sun, 01 Jun 2025 20:40:47 +0000

E aí, devs! vou fala um pouco mais sobre o projeto que estou criando que envolve desenvolvimento full-stack e cloud: meu novo Portfólio Pessoal com Blog e CMS integrados e tudo com o deploy que será feito na AWS. Essa experiência vai abranger vários pontos e com certeza vários desafios, que vou postando aqui nesse blog e descrevendo a minha experiência nesse projeto que vai do código às nuvens!

O Projeto: Visão Geral

A idéia é criar uma plataforma completa unificada para exibir meus trabalhos e compartilhar conhecimento técnico. O sistema é composto por:

Backend (API): Uma API robusta e completa desenvolvida com Node.js, TypeScript e Express. Ela já está pronta e lidando com posts do blog, tags, autenticação para o CMS (via JWT com bcryptjs), e até mesmo o envio de e-mails do formulário de contato usando AWS SES. Tudo isso conectado a um banco de dados PostgreSQL.

Frontend (React): Uma interface de usuário responsiva, construída com React e TypeScript, utilizando Vite para agilidade no desenvolvimento. O frontend consome a API para mostrar os posts, o formulário de contato, e em breve, a seção de portfólio e o painel de gerenciamento de conteúdo (CMS).

Tecnologias no Comando 🛠️

No Backend (API):

Linguagem: TypeScript
Runtime: Node.js
Framework: Express.js
Banco de Dados: PostgreSQL
Autenticação: JWT + bcryptjs
Serviços AWS: SES (para e-mails)

No Frontend

Biblioteca: React.js
Linguagem: TypeScript
Build Tool: Vite
Roteamento: react-router-dom
Este projeto não é apenas um portfólio; é um campo de aprendizado prático para arquitetura de software, boas práticas e, crucialmente, operações DevOps com foco em AWS. O backend já está 100% funcional, e o frontend está evoluindo rapidamente.

Quer dar uma olhada no código para ver a evolução? O repositório está aqui: https://github.com/marcelomagario/portfolio

Nos próximos posts, vou compartilhar mais sobre cada detalhes de cada tarefas e também os desafios do caminho. Valeu!

Desvendando o InvalidClientTokenId no AWS SES com Node.js e TypeScript: Aprendi uma lição que a “ordem dos fatores” importa sim.

Marcelo Magario — Sat, 31 May 2025 00:22:56 +0000

Desenvolver APIs é sempre um aprendizado, e por vezes nos deparamos com erros que, à primeira vista, parecem apontar para um lugar, mas a causa raiz está em outro.

Recentemente, ao integrar o AWS SES (Simple Email Service) no meu projeto pessoal de backend Node.js com TypeScript, me deparei com o frustrante erro InvalidClientTokenId. Este post detalha o problema, o processo de depuração e a solução.

O Cenário do Problema

Eu estava construindo o backend para o formulário de contato do meu portfólio pessoal. A ideia era que, ao preencher o formulário no frontend, o backend enviasse um e-mail para mim usando o AWS SES. Minha aplicação era construída com Node.js, TypeScript e Express.js, utilizando o @aws-sdk/client-ses para a comunicação com a AWS e o dotenv para gerenciar as variáveis de ambiente.
As credenciais da AWS (Access Key ID e Secret Access Key) estavam devidamente configuradas no meu arquivo .env, junto com a região da AWS e os e-mails de origem e destino para o SES. Minhas políticas de IAM na AWS garantiam acesso total ao SES para o usuário correspondente, e a identidade do e-mail de origem estava devidamente verificada na região correta do SES.

Tudo parecia estar em ordem, mas ao testar a rota de envio de e-mails, o servidor retornava uma mensagem de erro genérica. Ao inspecionar os logs detalhados do backend, a mensagem era clara:

InvalidClientTokenId: The security token included in the request is invalid..

A Persistência do Erro e a Confusão Inicial

Este erro da AWS geralmente indica que as credenciais de autenticação são inválidas ou estão ausentes. Naturalmente, minhas primeiras ações foram:

1. Verificar o .env: Confirmei que as chaves estavam lá, sem erros de digitação ou espaços extras.
2. Revisitar o IAM na AWS: Verifiquei se o usuário tinha as permissões corretas (inclusive com o AmazonSESFullAccess) e se a chave de acesso que eu estava usando no .env estava ativa no console da AWS.
3. Checar o AWS SES: Confirmei que o e-mail de origem estava verificado e que a região do SES correspondia à que estava no meu arquivo de variáveis de ambiente.

Apesar de todas as verificações apontarem que "estava tudo certo", o erro persistia. Tentei gerar novas chaves de acesso no IAM, apagar caches de credenciais locais que poderiam existir, mas a teimosia do InvalidClientTokenId continuava.

A Revelação Inesperada: undefined

A chave para desvendar o mistério veio quando decidi inspecionar o que o cliente do SES realmente estava "vendo" em tempo de execução. Adicionei um log estratégico no meu controller, exatamente no ponto onde o cliente SES era inicializado, para imprimir o valor da Access Key ID que estava sendo utilizada.

A saída foi chocante e reveladora: SES Client Access Key ID being used: undefined.

Isso significava que, embora a variável AWS_ACCESS_KEY_ID estivesse no meu arquivo .env e eu soubesse que ela era lida em algum momento, no instante em que o cliente SES estava sendo configurado, essa variável simplesmente não existia no ambiente do processo.

A Causa Raiz: A Ordem Importa!

O problema não estava nas credenciais em si, nem na falta de permissões, mas sim na ordem em que as coisas eram carregadas no meu aplicativo Node.js.

Em ambientes JavaScript com módulos (como o TypeScript é transpilado), as instruções de import no topo de um arquivo são processadas e seus módulos são executados antes que o restante do código do arquivo principal comece. No meu app.ts, a chamada para dotenv.config() (que carrega as variáveis do .env para process.env) estava posicionada abaixo das minhas declarações de import.

Meu app.ts importava a rota de contato.
A rota de contato, por sua vez, importava o controller de contato.
Quando o controller de contato era carregado e o cliente do SES era inicializado (uma ação que acontece no momento da importação do módulo), o dotenv.config() no app.ts ainda não havia sido executado.
Consequentemente, as variáveis de ambiente essenciais da AWS ainda não estavam disponíveis em process.env.
O cliente SES era instanciado com valores undefined para as credenciais, e a AWS naturalmente as rejeitava com o erro InvalidClientTokenId.

A Solução Definitiva

A solução foi simples, mas de impacto: mover a linha dotenv.config(); para o topo absoluto do meu arquivo app.ts, garantindo que ela fosse a primeira coisa a ser executada.

Com essa pequena, mas crucial, alteração, as variáveis de ambiente eram carregadas no process.env antes que qualquer outro módulo que dependesse delas fosse inicializado. O cliente SES, então, conseguia acessar as credenciais corretas, se autenticar com sucesso na AWS, e os e-mails começaram a ser entregues sem problemas.

Lições Aprendidas

Este problema reforçou algumas lições importantes no desenvolvimento de APIs:

1. A Ordem de Carregamento é Crucial: Em Node.js e TypeScript, a sequência de execução de módulos e inicializações pode ter um impacto significativo. Variáveis de ambiente precisam ser carregadas antes que qualquer código que as utilize seja executado.
2. Debug com console.log: Uma ferramenta simples como console.log pode ser incrivelmente poderosa para inspecionar o estado das variáveis e o fluxo de execução em um ponto específico do código.
3. Confie nos Logs, mas Depure o Contexto: O erro InvalidClientTokenId apontava para credenciais, e elas estavam corretas no .env. O desafio foi entender por que elas não estavam acessíveis no momento certo. O erro da AWS estava correto, mas a causa não era o valor da chave, e sim sua ausência no ambiente de execução.

Esta experiência foi um ótimo lembrete de como nuances no fluxo de execução de um aplicativo podem levar a desafios de depuração complexos, mas também de como uma abordagem sistemática e a inspeção direta do ambiente podem levar à solução.