DEV Community: Ortiz de Arcanjo António David

Por que contratar um Dev Remoto Angolano?

Ortiz de Arcanjo António David — Tue, 01 Sep 2026 14:06:57 +0000

Enquanto todo mundo disputa os mesmos devs caros nos EUA e Europa, existe um mercado inteiro de talento sendo ignorado: Angola.

Aqui vão 4 motivos reais:

Custo x Qualidade Formação sólida, bilíngue PT/EN, fuso GMT+1. Mesma qualidade técnica, investimento 3x menor. Oportunidade que gera impacto real.
Fome de Crescimento Aqui as vagas são poucas e muito concorridas. Quando um dev angolano recebe uma chance global, ele agarra com as duas mãos e entrega 200%.
Resiliência nível Hard Aprender a programar com poucos recursos te ensina a ser criativo e resolver problema. Qualquer desafio de produto é pequeno perto disso.
Pagamento? Resolvido SWIFT, Wise, Payoneer, Deel. Já não é mais desculpa. O dinheiro chega em USD.

Angola está cheia de talento que só precisa da primeira porta aberta.

Dê essa oportunidade. Você ganha um dev leal, dedicado e com algo pra provar. Nós ganhamos a chance de mostrar nosso valor.

Angola pode ser a nova Índia do desenvolvimento de software.

Aqui existem milhares de desenvolvedores resilientes, criativos e altamente qualificados. Gente que entrega resultado de excelência mesmo com poucos recursos, internet instável e prazos apertados.

A tua empresa pode contratar esse talento hoje.
Mesma qualidade de um dev da Europa/EUA. Custo muito menor. Impacto social gigante.

Dê a primeira oportunidade remota para um desenvolvedor angolano.
A tua empresa contrata talento e consequentemente muda a realidade de uma família inteira.

Trabalho Remoto - Como receber os Pagamentos

Ortiz de Arcanjo António David — Sun, 30 Aug 2026 21:29:08 +0000

Se enumerarmos os fatores que levantam dúvidas e atrapalham o primeiro passo no trabalho remoto, com certeza a forma de Pagamento e Recebimento do salário ocupa o 1º lugar.

A incerteza de como a empresa fará os pagamentos do salário e de como o Desenvolvedor vai receber, afasta as negociações.

Realidade de Angola

No meu caso, Angola não oferece condições para pagamentos internacionais como es da Europa e América, por exemplo. Esse favor coloca Angola fora de do mapa de trabalho remoto.

Há muitos casos em que a empresa opta por outros candidatos de países que facilitam essa transação. No meu caso, perdi e continuo a perder várias oportunidades de emprego, por causa dessa incerteza, desde o jurídico até o financeiro.

Métodos/ Sistemas Conhecidos

WISE
Revoult
Payoneer
USDT
Stripe
Nomes Global

Solução Oficial

A solução mais segura que encontrei foi a transferência internacional por meio do sistema SWIFT.

O que é o SWIFT?

Em poucas palavras: SWIFT é a forma oficial de transferências entre países. Todas transferências comerciais entrar países passam por esse sistema.

Estrutura do SWIFT

O Swift é formado pelo IBAN, Endereço do Banco, Código Swift, Registo Bancário, Contacto do Banco e Endereço do Beneficiário.

Como usar o SWIFT para pagamentos

Solicitar os dados SWIFT no seu banco.
Organizar os dados SWIFT num arquivo PDF ou Imagem
Fornecer os dados a Empresa
O valor chega em dólares, na conta do seu banco comercial
Converter o valor de USD para AOA

Observações

A transferência internacional com SWIFT pode durar de 3 a 5 dias úteis
Necessita de conversão por parte da Empresa, mas é simples
A transferência requer validação de N bancos intermediários e outras instituições
O beneficiário sofre pequenos descontos, totalizando aproximadamente 13 000 AOA

Resultado

No início duvidava desse método.
O primeiro contacto foi estranho pela demora mas ganhei confiança nesse método actualmente é o que mais confio.

Conclusão

O SWIFT pode ser a resposta que as empresas estrangeiras procuram durante o recrutamento de Profissionais Angolanos.
As empresas internacionais podem economizar muito, dando oportunidade aos programadores angolanos.

Exemplo

Em seguida forneço uma imagem com os dados necessários para uma transferência Swift, usando o banco BAI.

Para mais informações, contactar o seu banco pode trazer as melhores respostas.

Minha experiência: 1 ano de Trabalho Remoto

Ortiz de Arcanjo António David — Sun, 16 Aug 2026 21:59:30 +0000

Como começou

Em junho de 2025 comecei a trabalhar remotamente como Backend Engineer.
Stack: Python, MongoDB e Redis para o desenvolvimento de uma plataforma administrativa multi-organizações, focada no setor jurídico e com expansão para RH e financeiro de cada cliente.

3 meses depois ingressei em outra oportunidade como Golang Developer, desenvolvendo microsserviços para diferentes produtos: motor de assinatura de documentos, serviço de log e auditoria de sistemas, gestão completa de produtos e até controle de frota com autenticação OTP.

Depois de 1 ano trabalhando ativamente e de forma deliberada com a cultura remota, adquiri experiências que serão úteis em qualquer oportunidade. Acredito que é o formato que mais se identifica comigo: foco, testar, corrigir e entregar.

O que esses trabalhos têm em comum: orientação a resultado. São muitas demandas e todos os sistemas têm um requisito básico: multi-tenant. Eu já tinha noções sobre o tema, mas aprendi na prática a lidar com a complexidade de isolar dados sem vazamento entre organizações.

Evolução

Anteriormente eu tinha uma má impressão sobre o trabalho remoto. Como seria avaliado? Como mostrar resultados? Como ficariam as interações?
Com o tempo, essas questões se tornaram fáceis para mim.

Remoto não é desvantagem. Apenas exige um tempo de adaptação, tanto para a empresa quanto para o profissional.
Quem ingressa no remoto e colhe bons resultados, raramente deseja voltar ao formato 100% presencial.

Comparação com o presencial

O formato presencial é bom: há interações pessoais cara a cara, confraternizações, facilidade para explicar inquietações aos líderes e agilidade no dia a dia. Mas, felizmente, a área de software nos dá a possibilidade de trabalhar remoto e entregar mais resultados, abrindo mão apenas da interação pessoal.

Pontos fortes

Orientação a resultado
Eficiência
Reuniões mais curtas
Sem conversas paralelas
Obriga a automatizar processos de desenvolvimento

Desafios

Cobrança maior, pela falta de outros elementos de acompanhamento
Risco de acúmulo de tarefas em pouco tempo
Pouca interação pessoal, o que pode ser um problema para alguns
Questões documentais podem ser menos rigorosas

Conclusão

Espero permanecer por muitos anos trabalhando remotamente.
Tem sido satisfatório trabalhar nesse formato, de qualquer lugar, entregando resultados com pouca burocracia.

Como implementar No-Ops para Blindar Microsserviços em Go

Ortiz de Arcanjo António David — Tue, 12 May 2026 13:52:29 +0000

Muitas aplicações morrem (panic) porque um serviço de telemetria ou um broker de mensagens ficou offline por apenas 5 segundos.
Por que é que a minha API de vendas caiu se o problema foi no servidor de logs, de cache ou de tracing?

O sistema em produção deve resistir em caso de falha de infraestrutura. Para isso, basta definirmos prioridades e criticidade de acordo com o contexto da aplicação.

Conceitos-Chave

Fail Fast: Para a Database. Se não há dados, não há negócio. Trava o processo cedo.
Fail-Safe / Graceful Degradation: Para Observabilidade e serviços auxiliares. Se o Tracing caiu, a vida continua.
Null Object Pattern (No-Op): A técnica de implementar interfaces com métodos vazios (ou neutros) para evitar verificações de if resource != nil constantes no código de negócio.

Anatomia da Blindagem

A nossa estrutura de InfrapResources deve ser inteligente ao inicializar os contratos:

Hard Dependencies: Aquelas que definem o estado (ex: Postgres para transações, Redis para Auth).
Soft Dependencies: Aquelas que auxiliam o sistema (ex: RabbitMQ para eventos assíncronos, Prometheus, OpenTelemetry).

Base para a Implementação

A base da nossa resiliência reside na Programação por Contratos. Ao definirmos interfaces claras em ports, permitimos que a aplicação decida, em tempo de boot, qual "peça" encaixar:

A peça Real: Conecta ao serviço e executa operações reais.
A peça No-Op: Silencia falhas e mantém o sistema estável (executa uma operação "vazia").

Ambas respeitam rigorosamente os contratos de infraestrutura: Database, Cache, MessageBroker, entre outros.

Benefícios Reais

Developer Experience (DX): O programador não precisa de espalhar if r.Resource != nil em todo o lado. O contrato está lá e é seguro chamá-lo.
Resiliência: A app sobrevive em ambientes instáveis (como instâncias gratuitas ou clouds com flutuações de rede).
Testabilidade: No-Ops são, na prática, Mocks prontos para testes de integração e desenvolvimento local rápido.

Conclusão

Muita gente confunde resiliência com 'nunca falhar'. Na verdade, resiliência é saber o que fazer quando a falha acontece.
Implementar No-Ops em Go é uma das formas mais elegantes de garantir que o teu sistema não entra em pânico por causa de uma dependência não-crítica

Código Fonte:

https://github.com/ortizdavid/golang-pocs/tree/main/resilience

Gerenciamento de Cron Jobs em Golang

Ortiz de Arcanjo António David — Fri, 24 Apr 2026 15:02:56 +0000

Dando continuidade à nossa série sobre tarefas em segundo plano, hoje vamos focar em algo que todo o sistema robusto precisa: Cron Jobs.

Muitas vezes, precisamos executar uma tarefa em intervalos específicos: a cada 30 minutos, 15 segundos, ou a cada 2 horas.

Recapitulando: Worker vs Cron Job

Embora ambos rodem em background:

Worker: Foca no processamento contínuo (ex: consumir uma fila até que ela fique vazia).
Cron Job: Foca na recorrência agendada (ex: gerar um relatório de 15 em 15 minutos).

Exemplos comuns de Cron Jobs

Limpeza de arquivos temporários: Evitar que o disco fique cheio com logs antigos.
Relatórios de Negócio: Consolidar vendas do dia anterior.
Sincronização de Dados: Atualizar taxas de câmbio ou stocks de APIs externas.
Backup de Segurança: Realizar dumps periódicos de tabelas críticas.

O problema da falta de orquestração

Quando começamos a criar vários jobs espalhados pelo código, o problema aparece rápido:

Visibilidade: Quais tarefas estão ativas agora?
Resiliência: Se uma tarefa entrar em "panic", ela vai derrubar toda a minha API?
Encerramento Limpo: Se eu desligar o servidor, as tarefas param no meio do caminho corrompendo dados?

A solução é simples: um Cron Job Manager.

Passos para criação do Cron Job Manager

Definir uma Interface: Padronizar as operações necessárias, com nome, um tempo de agendamento e o método de execução.
Implementar o Engine com Tickers: Usar time.NewTicker para intervalos regulares.
Isolamento de Erros (Recover): Capturar e logar erros sem interromper o Manager.
Contexto de Cancelamento: Propagar o context.Context para que todas as Goroutines respeitem o sinal de paragem do sistema.

Vantagens desta Arquitetura

Graceful Shutdown: recebe o sinal de cancelamento do Sistema Operativo e avisa os jobs para terminarem as suas operações de forma segura.
Desacoplamento: O motor do Cron não conhece a regra de negócio; ele apenas executa "contratos".
Observabilidade: Centralização de logs, permitindo rastrear o início e o fim de cada operação.
Plug and Play: Adicionar um novo job é simples. Basta registarmos no Manager.

Código fonte: https://github.com/ortizdavid/golang-pocs/tree/main/cronjob-manager

Gerenciamento de Workers numa aplicação Golang

Ortiz de Arcanjo António David — Mon, 06 Apr 2026 14:02:04 +0000

Atualmente é indispensável que um sistema que cresce esteja preparado para processar tarefas em background.
Essas tarefas não devem interromper o fluxo normal da aplicação.
O melhor é estruturar como esses workers vão se comportar e permitir a configuração dos mesmos.

Felizmente, Golang nos dá a vantagem de criar estruturas que facilitam esse tipo de aplicações.
Usando Goroutines, channels e contextos de cancelamento, conseguimos criar essa estrutura.

Cron jobs VS Workers

Facilmente confundimos Cron Jobs com Workers. Eles partem do mesmo princípio de executar tarefas em segundo plano.

Worker: processa tarefas num ciclo infinito, usando a frequência e número de tentativas.
Cron Job: trabalha com agendamento, a tarefa é somente executada no tempo definido.

Exemplos mais comuns de Workers

Processamento de uma regra de negócio
Envio de dados para uma fila
Consumo e processamento de filas
Envio de e-mails recorrentes
Campanha de mensagens em massa
Envios de SMS

O problema de muitos workers

Quando a aplicação cresce, podemos ter várias tarefas por processar na aplicação.
Encadear cada tarefa torna o código difícil de ler e manter. Nesse caso, devemos achar uma estratégia para organizar e manter esse número de workers.
A forma mais elegante é o worker manager, organizador e orquestrador de workers, responsável pelo registro, chamada e ciclo de vida dos mesmos.

Passos para criação do Worker Manager

Definir uma interface para a base dos workers: Start, Stop e Worker Name
Criar o manager que agrupa os workers
Criar um mecanismo para iniciar e parar todos os workers
Se necessário, uma função para mostrar as infos dos workers registrados no sistema
Configurar o máximo de tentativas e o intervalo de tempo que os workers vão executar a operação

Vantagens

Graceful shutdown: o manager avisa a todos os workers quando parar. Eles não perdem dados, escutam o sinal de cancel e vão parando.
Estratégias de backoff
Modularidade
Código fácil de manter e evoluir
Arquitetura plug and play

No futuro veremos como implementar um cron job manager.

Código fonte: https://github.com/ortizdavid/golang-pocs/tree/main/worker-manager

Por que o seu Microserviço deve permitir Integração via JSON-RPC?

Ortiz de Arcanjo António David — Tue, 17 Mar 2026 17:48:02 +0000

Embora o REST seja o padrão absoluto para o Frontend, a comunicação entre serviços (Service-to-Service) pede algo mais direto e menos verboso.

O gRPC é frequentemente citado como a solução de elite, mas traz uma complexidade de infraestrutura (.proto, geração de código, HTTP/2) que muitos projetos não precisam no dia zero.
O JSON-RPC surge como o "pote de mel": simples como JSON, mas eficiente e intuitivo como uma chamada de função local.

Onde cada um brilha?

REST: Perfeito para recursos públicos. Focado em substantivos (/users).
gRPC: Ultra-performance e streaming. Focado em contratos rígidos (Binário).
JSON-RPC: O melhor para comunicação interna ágil. Focado em ações (User.Create). É nativo em Go e não exige ferramentas externas.

Implementação Enterprise: O que não pode faltar

Para um sistema robusto, não basta apenas "rodar" o RPC. É preciso controle:

Capabilities: O serviço deve ser capaz de se "auto-apresentar", listando métodos disponíveis via reflexão no arranque.
Rastreabilidade: Cada chamada deve carregar um Trace-ID no Contexto para que saibas exatamente quem iniciou a cadeia de ações.
Segurança (Internal Key): Autenticação rápida via Headers (X-Internal-Key) para garantir que apenas serviços autorizados acedam ao motor RPC.

O Desafio da Memória em Go

Um detalhe crítico ao implementar RPC em Go com transações de base de dados: Cuidado com a estabilidade dos ponteiros.

Ao usar closures (funções anónimas) dentro de transações, evita declarar ponteiros nulos para o retorno. Se tentares preenchê-los apenas dentro da transação, podes enfrentar problemas de visibilidade de memória (Race Conditions) que resultam em nil pointer dereference.

A Boa Prática: Inicializa sempre a tua struct de resposta (new(Struct) ou &Struct{}) antes de entrar na transação. aIsso garante um endereço de memória estável e evita que o teu Dispatcher RPC sofra um Panic.

Configurações e Limites

Um motor RPC robusto precisa de fronteiras claras:

Timeouts: Controle rígido para que uma chamada não "prenda" o serviço infinitamente.
Payload Limit: Evita que requisições gigantes saturem a memória do servidor.
Observabilidade: Logs automáticos de cada método invocado, incluindo a latência e o status da resposta.

Conclusão

Adotar JSON-RPC na arquitetura interna reduz o overhead de roteamento, facilita o debug (é legível, ao contrário do gRPC) e mantém o código limpo.
É a escolha de quem prefere resolver problemas de negócio a lutar contra a infraestrutura.

O JSON-RPC dá ao teu sistema a fluidez de uma chamada de função com a robustez de um microserviço.

Minha experiência com gRPC e Golang: Construindo um Motor de Assinatura Digital

Ortiz de Arcanjo António David — Wed, 04 Mar 2026 10:25:37 +0000

Nas últimas duas semanas, aceitei um desafio técnico intenso: desenvolver um microserviço de assinatura digital utilizando Go e gRPC.
Foi um projeto que me tirou da zona de conforto (resolver problemas de negócio puros) e me mergulhou profundamente em engenharia de infraestrutura e criptografia.

O Desafio Técnico

O objetivo era criar um motor de processamento capaz de receber documentos financeiros em XML, realizar o parse, garantir a integridade via algoritmos de assinatura digital e retornar o documento assinado de forma única.
Tudo isso com foco em alta performance e disponibilidade.

Stack de Engenharia

Para suportar essa complexidade, utilizei uma stack robusta:

Go & gRPC: Escolhidos pela necessidade de baixa latência e comunicação eficiente machine-to-machine (evitando o overhead do JSON/REST).
HashiCorp Vault: Gestão segura de segredos e chaves privadas (Secret Manager).
MinIO: Armazenamento de objetos para os arquivos de certificados (.pfx).
MySQL & Redis: Persistência de metadados e camada de cache para otimização de consultas.
Criptografia X.509: Lógica para extração de metadados e validação de cadeias de confiança.

Destaques de Implementação

A arquitetura foi pensada para garantir a idempotência e a segurança em repouso, pilares fundamentais em sistemas que lidam com documentos financeiros sensíveis.

Segurança Multitenant: O sistema permite que cada consumidor gerencie seu próprio certificado, isolado e protegido por criptografia através do Vault.
Performance: Sem interface gráfica e focado em processamento pesado, o gRPC garantiu que múltiplos sistemas pudessem consumir o serviço simultaneamente com estabilidade.
Cultura de Testes: Para validar a resiliência, desenvolvi scripts de automação em Bash e utilizei o grpcurl para testes de stress, simulando múltiplos clientes em simultâneo.

O Aprendizado

A grande conclusão prática é que o gRPC é a escolha de excelência para integração entre sistemas onde estabilidade e processamento pesado são inegociáveis. Trabalhar com criptografia e certificados digitais é uma área complexa, mas extremamente gratificante quando vemos os resultados de performance validados na prática.

Mais um conhecimento adquirido e pronto para ser aplicado em soluções de escala global!

Como implementar Injeção de Dependências em Go manualmente?

Ortiz de Arcanjo António David — Mon, 23 Feb 2026 17:13:19 +0000

A linguagem Go permite controlar manualmente as dependências com mais facilidade.
Cada item da sua aplicação pode ser instanciado onde o desenvolvedor desejar. Go nos dá essa liberdade.

Mas, com o crescimento do projeto, é importante arranjar uma estratégia para carregar as dependências, porque elas podem afetar positiva ou negativamente a aplicação.
Essa liberdade do Go pode dar margem para vários erros de dependências. Para projetos pequenos, faz sentido, mas para grandes projectos pode ser difícil de manter.

Cenário comum: main inflado

Instanciar DB, cache, configs no main
Instanciar repos, services
Criação e inicialização dos componentes Isso Faz sentido para projetos com poucos componentes, não reprsenta grandes riscos.

Solução: injeção via containers

Criar container de infraestrutura: DB, Cache, Logger, Mensageria e outros.
Container de serviços: regras de negócio
Container de repositórios: interação com a base de dados No Main, só precisamos carregar os containers. o Main se torna o maestro da aplicação.

Vantagens

Criação dos objetos 1 vez apenas
Organização dos componentes
Separação de responsabilidades
Performance melhorada

Por que fazer isso manualmente?

Embora existam bibliotecas como Google Wire ou Uber FX, fazer a gestão manual com containers traz:

Performance: Sem uso de reflection em tempo de execução.
Transparência: Você vê exatamente o que está sendo injetado e onde.
Singleton por Design: Objetos pesados (como pools de DB) são criados apenas uma vez.
Testabilidade: É fácil substituir um repositório real por um mock nos seus testes.

Código-fonte

Como tens organizado as dependências nos teus projetos? Abordagem manual ou usas bibliotecas?

Entrypoint API: Por que o seu /health não é suficiente?

Ortiz de Arcanjo António David — Thu, 19 Feb 2026 11:03:05 +0000

A maioria das APIs limita-se a retornar um simples status para verificar se funciona ou não, mostrando apenas o estado da aplicação.

Ambientes sérios

Em ambientes de produção, não basta saber se a aplicação está ativa.
É necessário saber se os recursos essenciais da API estão disponíveis:

Base de dados
Cache
Storage
Serviços externos críticos

Se um desses componentes estiver indisponível ou em modo degradado, o consumidor precisa saber antes de executar operações mais pesadas.

Outro ponto importante é disponibilizar um pequeno mapa da API para situar o consumidor (integrador e frontend), expondo:

Nome do serviço
Estado atual
Principais endpoints
Links úteis (health, info, documentação)

Por que essa preocupação?

Esses itens são importantes para evitar overhead no consumo da API.

Evita requisições desnecessárias
Reduz falhas previsíveis
Previne erros em cascata
Permite que o frontend aplique estratégias de contingência
Melhora a experiência de integração

O frontend pode, por exemplo, verificar o estado do storage antes de iniciar um upload grande.

Como resolver?

A API pode disponibilizar no entrypoint principal:

Um mapa simples do serviço
Estado detalhado dos recursos críticos
Links principais da aplicação

Também pode expor informações não críticas sobre o ambiente, como:

Limites de upload
Versão da API
Configurações relevantes
Capacidades habilitadas

Isso permite que o consumidor saiba como interagir com o serviço antes de iniciar operações.

Conclusão

Isso eleva a API de um simples backend para uma solução mais robusta e consciente da experiência do consumidor.

Reduz requisições desnecessárias
Diminui erros evitáveis
Aumenta a previsibilidade
Melhora a qualidade do serviço

Template Python MongoDB API: Arquitetura (Ferramentas)

Ortiz de Arcanjo António David — Wed, 14 Jan 2026 10:37:37 +0000

Um backend de alto nível exige peças que garantam performance e escalabilidade. Para este template, selecionei uma stack focada em prontidão para produção.

🛠️ O Ecossistema

Linguagem: Python 3.11+
Framework: FastAPI (Async)
Banco de Dados: MongoDB
Cache & Segurança: Redis
Storage: MinIO, Filesystem e Google Storage
Observabilidade: Prometheus, Grafana e Jaeger
Infra: Docker & Docker Compose

🎯 O porquê de cada escolha:

⚡ FastAPI

Por que: Alta performance com asyncio e documentação automática (Swagger). Agiliza o desenvolvimento com validação rigorosa.

🍃 MongoDB

Por que: Flexibilidade de schema com JSON. Permite evoluir o banco de dados sem a burocracia de migrações complexas.

🧠 Redis

Por que: Baixíssima latência. Ideal para cache de sessões e Blacklist de tokens JWT e Rate Limiting, protegendo o banco principal de sobrecarga.

📦 MinIO & Multi-storage

Por que: Compatibilidade com Amazon S3. Desacopla arquivos do banco de dados e permite migrar para qualquer nuvem facilmente.

📊 Prometheus & Grafana

Por que: Visibilidade total. Monitora a saúde da API, latência e recursos em tempo real.

🐳 Docker

Por que: Portabilidade absoluta. Garante que o sistema rode idêntico em qualquer ambiente (Cloud-native).

Conclusão: Uma base sólida para sair do zero direto para o nível corporativo.

O que achou dessa stack? No próximo post, vou detalhar a organização das Camadas para garantir manutenção e escala.

Código fonte: https://github.com/ortiz-python-templates/python-mongodb-api

Identidade e Segurança — Autenticação (Python Template Mongo API)

Ortiz de Arcanjo António David — Wed, 14 Jan 2026 10:33:42 +0000

Para sistemas modernos, autenticação não é apenas "validar usuário e senha". É sobre garantir persistência segura, performance e rastreabilidade.
Neste exemplo, implementamos um fluxo completo utilizando FastAPI, MongoDB, JWT, Redis e Middleware.

Componentes chaves da solução

Dual Token Strategy (Access e Refresh):
- Access Token: Curta duração, enviado via Header ou Cookie para autorizar requisições.
- Refresh Token: Longa duração, armazenado via HttpOnly para gerar novos access tokens com segurança.
Middleware de Autenticação: Camada que intercepta as requisições e valida os tokens, liberando automaticamente as rotas públicas (/login, /docs, /health).
Token Blacklist (Redis): Gerenciamento de estado para tokens revogados durante o logout, impedindo ataques de replay.
Login Activity Tracking: Captura rica de dados do ambiente (Dispositivo, Navegador, SO, IP) usando device-detector para auditoria e segurança.

Fluxo de Login (Passo a Passo)

Requisição de Login: O cliente envia email e password. O AuthService valida as credenciais no MongoDB.
Geração e Persistência: O JwtService gera os tokens. Eles são injetados na resposta como Cookies HttpOnly, uma barreira crucial contra ataques XSS. 3.Registro de Atividade: O LoginActivityService analisa o 'User-Agent' e salva o snapshot do acesso (dispositivo e localização).
Middleware em Ação: Em cada rota protegida, o Middleware extrai o token, verifica se não está na Blacklist do Redis, valida o usuário e o anexa ao request.state.
Ciclo de Refresh: Quando o Access Token expira, o endpoint /refresh-access-token valida o Refresh Token e emite um novo par, mantendo a UX sem interrupções.

Conclusão

Este fluxo foi pensado para ambientes reais de produção, indo muito além do básico de tutoriais.
A combinação de Stateless JWT com Stateful Blacklist (Redis) oferece o melhor dos dois mundos: escalabilidade e controle.
Na próxima parte, falaremos sobre autorização baseada em Roles & Permissions.

Código Fonte: https://github.com/ortiz-python-templates/python-mongodb-api