DEV Community: Ortiz de Arcanjo António David

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

🚀 Production-Ready FastAPI Template (Python)

Ortiz de Arcanjo António David — Thu, 18 Dec 2025 16:39:17 +0000

Depois de anos desenvolvendo APIs e sistemas backend em produção, organizei e liberei o template que uso como base para projetos reais.

O objetivo é simples: começar novos produtos já com arquitetura sólida, segurança, observabilidade e produtividade desde o primeiro commit.

🧩 O que este template entrega:

🔐 Identity & Security

Users, Roles & Permissions
JWT (access + refresh tokens)
Redis para blacklist de tokens, cache e rate limit
Login Activity tracking (auditoria de acessos)
Middlewares de autenticação e autorização

🗄️ MongoDB bem estruturado

Base model reutilizável (base_mongo_model)
Repositórios separados (Query / Command)
Índices, views e modelos organizados por domínio

⚙️ Configurações do sistema

Basic Configurations
Company Configurations
Feature Flags nativas

📦 Storage

MinIO (S3-compatible)
Google Cloud Storage
Filesystem local
Upload/download seguro
Gestão de user attachments

📨 Emails

Envio de emails transacionais
Templates HTML prontos
Estrutura simples para novos tipos de email

📊 Observabilidade & Infra

Docker & Docker Compose
Logging estruturado
Tracing com OpenTelemetry / Jaeger
Métricas prontas para Prometheus
Dashboards Grafana

🧰 Features enterprise

Feature Flags por ambiente
Rate limiting
CORS configurável
Healthcheck completo
- MongoDB
- Redis
- Storage
- CPU, RAM e disco

🧱 Arquitetura limpa

Código fácil de ler e manter
Arquitetura direta ao ponto (sem overengineering)
Organização por domínio (identity, configurations, files, etc.)
Separação clara: controllers, services, repositories, schemas e models

🛠️ Produtividade

Makefile automatizado
- comandos Docker
- comandos Python
- setup rápido de ambiente
Boilerplate mínimo, foco no que importa

🎯 Ideal para:

Startups que querem lançar rápido sem dívida técnica
Empresas que precisam padronizar FastAPI
Devs backend que trabalham com sistemas reais
APIs, microserviços, SaaS e ERPs

🔗 Repositório (Open Source):
👉 https://github.com/ortiz-python-templates/python-mongodb-api

Feedbacks e contribuições são muito bem-vindos 🚀

🔒 Aviso (importante)

Template pensado para produção real: código legível, arquitetura objetiva e ferramentas que aceleram o dia a dia do backend.

Como desenvolver software de forma ágil mesmo com poucos requisitos

Ortiz de Arcanjo António David — Fri, 31 Oct 2025 08:42:11 +0000

As metodologias ágeis trouxeram muitos benefícios para o desenvolvimento de software nos tempos modernos.

Mas nem tudo são flores.
Há coisas que não se encaixam na prática — cada empresa tem a sua estrutura, os seus problemas e as suas particularidades.

Grandes frameworks de agilidade podem, às vezes, complicar mais do que ajudar.
O mundo real é caótico — e é preciso adaptar o ágil à realidade de cada empresa.

Para o desenvolvedor, o essencial é usar a experiência para se adaptar e manter a produtividade.
Mesmo com poucos requisitos, é possível entregar valor e gerar impacto.

Factores externos

Informações nebulosas
Requisitos limitados
Experiência reduzida da equipa
Prazos curtos para o lançamento

Nestes casos, o que realmente orienta o desenvolvimento é a habilidade em arquitetura e design de software.

Sugestões práticas

Observar cenários semelhantes
Pesquisar softwares da mesma natureza
Adaptar o sistema a padrões internacionais

Resolução do problema

O que funciona é um acordo entre a equipa, reduzindo burocracias e focando no essencial.

Até o WhatsApp pode ser mais ágil que muitas ferramentas complexas.

Fluxo rápido que funciona na prática

Identificar o problema
Definir requisitos mínimos
Fazer um rascunho simples
Criar uma branch para resolver o problema
Implementar a funcionalidade
Push + Merge

No fim das contas, o que faz a diferença não é o método, mas a capacidade de adaptação.
Os melhores desenvolvedores são os que transformam o caos em clareza e o pouco em resultado.

A refactoração é uma tarefa complexa

Ortiz de Arcanjo António David — Sat, 25 Oct 2025 20:04:37 +0000

A refactoração, ao contrário do que a teoria sugere, é uma tarefa muito complexa. Os livros e artigos costumam mostrar exemplos de funções simples e classes pequenas, mas o mundo real está muito distante dessa visão superficial.
Projectos reais carregam uma história — um conjunto de decisões que foram tomadas ao longo do tempo e que levaram o código ao estado actual.
 É comum pensar que o projecto está desorganizado ou que não segue boas práticas, mas muitas dessas decisões foram influenciadas pela pressão do negócio e pela necessidade de entregar rápido.

Contexto de projectos reais

Em projectos reais, é comum encontrar arquivos com milhares de linhas. O que realmente ajuda é entender os padrões, perceber a intenção original e agir com cuidado.
Refactorar é muito diferente da teoria. Não se trata apenas de mudar o nome de uma classe, struct ou arquivo — há muitas variáveis envolvidas.

Algumas técnicas que ajudam

Identificar código repetido
Mover abstrações para helpers
Fazer refactorações pequenas e seguras, em vez de grandes mudanças de uma só vez Em outras linguagens, seria comum dividir grandes arquivos em várias classes. Mas em Go, a estrutura da linguagem facilita bastante esse processo.

Refactoração em Go

A linguagem Go ajuda muito na refactoração:

Funções a nível de pacote
Structs a nível de pacote
Facilidade em isolar helpers, mesmo sem classes Além disso, usar uma boa IDE faz toda a diferença — facilita navegar, testar e refactorar com segurança.

Refactorar é mais sobre compreender o contexto do código do que apenas reescrever funções. É um processo de respeito pela história do projecto e de construção de algo melhor, passo a passo.

Estrutura de um Projecto de Back-end

Ortiz de Arcanjo António David — Mon, 22 Sep 2025 09:58:45 +0000

Criar software ao longo do tempo pode se tornar uma tarefa difícil. À medida que as funcionalidades crescem, é necessário organizar o projeto para facilitar evolução e manutenção.

Por isso, compartilho uma sugestão que tenho aplicado nas minhas soluções e que tem funcionado muito bem.

Esta estrutura é simples, independente da linguagem, e ajuda a evoluir o projeto de forma mais organizada.

A ideia principal é separar código fonte, scripts e arquivos de configuração.

Estrutura Genérica

src: código fonte da aplicação (core e common)
database: migrações, seeds e scripts de banco de dados (SQL e MongoDB)
docker: arquivos de configuração Docker e Docker Compose
docs: documentação do projeto (API, arquitetura, regras de negócio)
generic: guia de organização genérica, referência para estruturar o projeto
observability: monitoramento e métricas (Grafana, Prometheus)
public: arquivos públicos, imagens, estáticos e templates (emails, relatórios)
scripts: scripts auxiliares (build, deploy, jobs)
tests: testes automatizados
ponto de entrada / EntryPoint: Ex: main.go, app.py ou Program.cs. Faz o setup dos middlewares, controllers e seed

Repositório

https://github.com/ortizdavid/backend-project-structure

O Culto à Ignorância

Ortiz de Arcanjo António David — Mon, 15 Sep 2025 11:37:56 +0000

Atualmente nas redes sociais cresce uma onda perigosa: a banalização da educação formal e a exaltação da ignorância.
Casos isolados de sucesso financeiro são usados para demonizar a formação acadêmica.

Frases comuns

"Não preciso de estudos, só de visão."
"Bill Gates não terminou a faculdade."
"Conheço pessoas que abandonaram a escola e são bem-sucedidas."
"Não preciso de estudo, preciso de conexões."

Verdades duras

Negócios podem falir por pura ignorância.
Dispositivos eletrônicos só existem graças a décadas de experimentos científicos.
Estratégias de marketing nasceram em ambientes acadêmicos.
Motores, vacinas, redes sociais e a internet são frutos de pesquisa e estudo.

Importância do conhecimento

Nosso avanço civilizacional se deve à ciência, à literatura, ao pensamento crítico.
Sem isso, não teríamos vacinas, nem sementes que salvaram milhões da fome, nem a tecnologia que nos conecta agora.

Cenário atual

A ignorância se tornou lucrativa. Idiotas falam com certezas absolutas enquanto sábios duvidam.
Conteúdos rasos viralizam. Pesquisa séria é ignorada.
E a juventude está sendo moldada por isso.

O Risco Futuro

Se a sociedade continuar nesse culto à ignorância, estaremos perdidos:

Não haverá inovação.
Não haverá quem dedique a vida a entender padrões e criar soluções.
A humanidade entrará em colapso.

Precisamos resgatar o valor do conhecimento.
A ciência, a educação e o pensamento crítico são os verdadeiros motores da humanidade.

A ignorância pode dar likes, mas nunca construiu um motor.
Sem conhecimento não há futuro.