Desenho De Bff Fácil

Por que a maioria dos BFFs vira um emaranhado

Eu já passei por isso ao montar microserviços para um app de delivery. O time de mobile pedia um endpoint novo toda semana porque as telas eram diferentes. Resposta rápida: criar um BFF pra cada cliente. Front-end web tinha um BFF, app Android outro, app iOS outro. Todo mundo repetindo as mesmas consultas aos serviços de backend, só que com nomes diferentes. Três meses depois, um bug na API de preços precisava ser corrigido em três BFFs separados. A solução foi mais simples do que parecia. Parei de pensar em BFF como uma camada nova pra cada cliente e comecei a tratar como uma abstração de composição. Chamei o serviço de pagamentos uma vez, transformei o payload pro formato que cada front-end precisava, e pronto. Sem repetição.

Desenho de bff fácil começa com um mapa

O primeiro passo é levantar os endpoints que o front-end realmente chama. Não o que você acha que ele chama, o que ele realmente chama. No caso do delivery, o app fazia 14 requisições por tela de carrinho. Catorze. Quinze se contar o check-out. O backend de pedidos respondia com dados demais, e o app filtrava no cliente. Era um desperdício de banda e de processamento. Minha solução foi desenhar um único BFF que agregava esses 14 endpoints em 3. Um pra listagem de restaurantes, outro pra detalhes do pedido, outro pra checkout. O front-end passava a fazer 3 requisições, o BFF fazia as 14 internamente e retornava o que importava. Redução de 70% nas latências percebidas pelo usuário.

A regra que ninguém conta

A maioria dos desenvolvedores tenta resolver o desenho de bff fácil criando uma classe nova por fluxo. Acaba com 40 classes de transformação para 3 fluxos reais. O problema é que BFF não é sobre mapear entidade. É sobre mapear intencionalidade do front-end. No projeto de delivery, eu fiz algo contra-intuitivo: parei de expor endpoints REST no BFF. Comecei a expor operações. Em vez de GET /restaurantes/{id}, tinha POST /fetch-detalhes-restaurante com payload { id, incluirAvaliacoes: boolean }. O BFF decidia internamente quantas chamadas fazer e como montar a resposta. Isso simplificou o código do front-end porque ele não precisava saber que existiam 3 microserviços.

Um problema real que eu enfrentei

Num outro projeto, de saúde, o BFF precisava combinar dados de 5 serviços. Prontuário, agendamento, prescrição, laboratório, farmácia. A latência do mais lento ditava o tempo de resposta. Laboratório levava 800ms. O front-end esperava 2 segundos. A solução foi usar chamadas paralelas com fallback. Se laboratório demorasse mais de 500ms, eu retornava o que eu tinha e pedia o resto em background. O usuário via a tela 600ms depois, não 2s. Não era perfeito, mas era acceptable. O time de produto aprovou porque a percepção de velocidade melhorou 3x.

O que eu aprendi com isso

BFF não é uma camada técnica. É uma camada de trade-off. Cada decisão de transformar ou delegar é uma escolha entre latência, complexidade e manutenibilidade. O desenho de bff fácil não existe quando você tenta otimizar tudo. Existe quando você aceita que 80% do trabalho pode ser simplificado deixando 20% serem difíceis. No meu tempo, eu vejo time que passa duas semanas desenhando BFF pra um sistema simples de e-commerce. Duas semanas. Eu fiz o mesmo em dois dias. A diferença foi que eu não tentei prever todos os cenários. Eu mapeei os 5 endpoints mais usados, criei uma transformação básica, e deixei o resto para depois. Quando veio o cenário novo, eu ajustava. Não refazia tudo.

Limitações que merecem ser ditas

BFF tem custo. Cada instância adicional precisa ser monitorada, versionada e testada. Num cenário com 100 microserviços e 5 BFFs diferentes, a complexidade de deploy aumenta. Não recomendo BFF para sistemas pequenos com menos de 5 endpoints expostos. O overhead de manter a camada supera o ganho. Também não recomendo BFF quando o front-end é nativo multi-plataforma com muito compartilhamento de lógica. Nesses casos, uma SDK interna ou biblioteca compartilhada resolve melhor. BFF brilha quando cada cliente tem necessidades diferentes de dados, não quando todos querem os mesmos dados. A alternativa mais simples que eu uso hoje é API Gateway com transformação de payload. Sem classe nova. Sem serviço extra. Só config. Funciona bem quando você não precisa de agregação complexa. Se precisa, aí sim BFF faz sentido.

O código que eu recomendo começar

Não preciso de framework. Um controller com 3 métodos resolve 90% dos casos. Um service que orquestra as chamadas. Um mapper que transforma. Pronto. Se crescer além disso, review se o problema é BFF ou se é problema de backend mal desenhado. No final, desenho de bff fácil é isso: mapear o que o front-end precisa, não o que o backend expõe. O resto é implementação.