A Engenharia por trás do BFF: Por que escolhemos Go para orquestrar nossos Canais Digitais
Por Yan Vitor Almeida Araujo — Tech Lead em Front-end/Mobile
A Engenharia por trás do BFF: Por que escolhemos Go para orquestrar nossos Canais Digitais
Por Yan Vitor Almeida Araujo — Tech Lead em Front-end/Mobile
Na era das IAs generativas e do código gerado por copilotos, a discussão sobre sintaxe de linguagem de programação tornou-se secundária. O que realmente define o sucesso ou o fracasso de uma arquitetura de canais digitais — especialmente quando lidamos com aplicativos móveis de altíssimo tráfego — são três pilares: Gerenciamento de I/O, Latência na ponta e FinOps (Custo de Nuvem).
Liderando o desenvolvimento de plataformas digitais, deparei-me com um desafio clássico: como construir a camada de Backend for Frontend (BFF) perfeita?
O BFF não é o lugar para regras de negócio pesadas. Ele é um maestro. Seu papel é receber a requisição do aplicativo móvel, fazer o padrão Scatter-Gather (disparar chamadas simultâneas para dezenas de microsserviços legados e gateways), agregar os dados, limpar o lixo e devolver um payload JSON enxuto e perfeito para a tela do usuário.
Para essa missão, colocamos as principais tecnologias do mercado à prova.
O Embate de Gigantes: Node, Kotlin, Python e Go
A escolha padrão de muitas equipes de front-end é o Node.js com TypeScript. O isomorfismo é incrível: a mesma equipe que escreve o React Native escreve o BFF, compartilhando contratos de tipagem. No entanto, em ambientes corporativos de alta conformidade e escala maciça, o enorme ecossistema de dependências (NPM) e as limitações de tráfego de thread única acendem um alerta para as equipes de AppSec e SRE.
Outras equipes corporativas defendem o Kotlin ou Java (Spring Boot). São robustos e confiáveis, mas trazem o peso da JVM. Levantar containers pesados de 1 vCPU e 2GB de RAM apenas para orquestrar chamadas de rede é o equivalente arquitetural a usar um caminhão de carga para entregar uma pizza. O custo na nuvem (AWS Fargate, por exemplo) escala agressivamente.
O Python, apesar de ser o rei indiscutível na engenharia de IA e dados, sofre com o GIL (Global Interpreter Lock) quando o assunto é concorrência pura de rede de altíssima volumetria.
Foi então que olhamos para a infraestrutura moderna e testamos o Go (Golang).
A Decisão por Go: Uma Escolha Focada em FinOps e Latência
Desenhado pelo Google para resolver problemas de infraestrutura em escala, o Go brilha na camada de borda (Edge/BFF) por razões que vão além do código:
- Concorrência Levada a Sério: Diferente de threads tradicionais do sistema operacional, o Go usa Goroutines. Um único container consegue disparar milhares de chamadas HTTP simultâneas consumindo frações de memória. A orquestração das APIs no BFF passa a ocorrer no limite físico da rede, zerando o overhead da linguagem.
- Eficiência Extrema de Nuvem (O Impacto no AWS Fargate): Um BFF em Go roda perfeitamente nas menores instâncias possíveis da nuvem (ex: tarefas de 0.25 vCPU e 512MB de RAM no Fargate). O binário estático consome cerca de 15MB em repouso. A redução de custo em comparação com um cluster equivalente rodando na JVM chega a ser na ordem de 60% a 70% na fatura mensal de processamento.
- Resiliência e Segurança Nativas: Com uma biblioteca padrão riquíssima, o Go nos permite levantar servidores HTTP, gerenciar roteamento, controlar contextos de timeout (cancelando chamadas em cascata se uma API externa demorar) e tratar concorrência sem instalar um único pacote de terceiros crítico. A superfície de ataque de Supply Chain despenca.
A Prova de Conceito: Resiliência no Mundo Real
Para validar a tese, construímos uma PoC integrando o BFF com APIs públicas brasileiras (BrasilAPI) simulando um Dashboard financeiro. O BFF precisava buscar, em paralelo: dados de agência, validação de CEP e as taxas do CDI.
Utilizando o pacote errgroup do Go, amarramos um limite de tempo estrito (Hard Timeout via Context). Se o gateway principal não responder em 2 segundos, a goroutine morre graciosamente, cancela as outras requisições pendentes e retorna o que chamamos de Degradação Graciosa: a tela do app mobile recebe os dados parciais e uma flag avisando que o serviço específico está temporariamente indisponível. Sem spinners infinitos, sem quebras no aplicativo.
O Veredito para a Cultura de Engenharia
Adotar Go em uma squad focada em front-end ou mobile exige maturidade e disposição para enfrentar uma curva inicial de aprendizado — especialmente com a verbosidade do tratamento de erros (if err != nil).
No entanto, o papel da arquitetura de software é justamente tomar as decisões difíceis nos bastidores para que a experiência na ponta seja irretocável. Ao adotar o Go para a orquestração do BFF, trocamos um pequeno custo de desenvolvimento inicial por um sistema brutalmente rápido, financeiramente otimizado e pronto para escalar sem gargalos de memória.
Na era da IA e da comoditização da sintaxe, dominar os conceitos de arquitetura, hardware e redes é o que diferencia os executores dos verdadeiros engenheiros de software.
E na sua empresa? O seu BFF atual está otimizando a experiência do usuário ou apenas inflando a conta da AWS?
메타데이터
- post_id
- 09460ec07321
- slug
- a-engenharia-por-trás-do-bff-por-que-escolhemos-go-para-orquestrar-nossos-canais-digitais-09460ec07321
- url
- https://medium.com/@yanaraujo1031/a-engenharia-por-tr%C3%A1s-do-bff-por-que-escolhemos-go-para-orquestrar-nossos-canais-digitais-09460ec07321
- canonical_url
- https://medium.com/@yanaraujo1031/a-engenharia-por-tr%C3%A1s-do-bff-por-que-escolhemos-go-para-orquestrar-nossos-canais-digitais-09460ec07321
- author_url
- https://medium.com/@yanaraujo1031
- status
- ok
- fetched_at
- 2026-06-21 12:17:11