O que é Backend for Frontend (BFF)?

Um Backend for Frontend (BFF) é um serviço de backend dedicado construído para um frontend específico. Em vez de cada cliente (web, iOS, Android, terceiros) conversar com o mesmo backend de propósito geral, cada um recebe sua própria camada do lado do servidor que agrega e reformata dados de seus microsserviços exatamente no payload que essa interface precisa.

Sam Newman nomeou e popularizou o padrão em 2015, baseado em trabalhos realizados no SoundCloud. Mais de uma década depois, o padrão BFF ainda é uma ferramenta padrão para equipes que executam microsserviços por trás de múltiplos aplicativos cliente, e a Microsoft o documenta como um padrão de arquitetura de nuvem central.

O problema que um BFF resolve

Imagine um sistema que começou com um único aplicativo web e um único backend. O backend expunha endpoints REST, o aplicativo web os consumia, e a vida era simples. Então a empresa lançou um aplicativo móvel. Depois uma integração com parceiros. Depois um widget de smartwatch. De repente, quatro clientes muito diferentes estão todos puxando do mesmo backend, e esse backend está tentando agradar a todos ao mesmo tempo.

Isso cria dois problemas recorrentes.

Excesso e falta de dados (over-fetching e under-fetching). Um endpoint de propósito geral retorna um formato fixo de dados. Um painel de desktop pode querer o registro completo do cliente com histórico de pedidos, recomendações e configurações de conta em uma única resposta. Um aplicativo móvel em uma conexão celular instável quer três campos e nada mais. Quando ambos acessam o mesmo endpoint, um deles obtém a quantidade errada de dados. O cliente móvel ou baixa um payload inchado que precisa descartar (over-fetching) ou precisa fazer várias viagens de ida e volta extras para reunir o que precisa (under-fetching).

Clientes 'tagarelas' (chatty clients). Quando um backend não é adaptado a uma tela, o cliente compensa fazendo muitas chamadas. Uma tela inicial móvel que precisa de dados de perfil, contagem de notificações e um feed pode disparar três ou quatro requisições separadas para três ou quatro microsserviços, e então juntar os resultados no dispositivo. Cada viagem de ida e volta extra custa latência e bateria, e a lógica de orquestração vaza para o cliente, onde é difícil de testar e versionar.

A tensão fundamental é tanto organizacional quanto técnica. Um backend compartilhado tem demandas concorrentes de cada equipe de frontend. A mudança de uma equipe precisa ser validada em relação às necessidades de todas as outras equipes antes de ser lançada, o que transforma o backend em um gargalo e uma fonte de atrito entre equipes.

Como o padrão BFF funciona

O padrão BFF introduz uma camada fina do lado do servidor que se posiciona entre um frontend e seus serviços downstream. Cada interface obtém seu próprio backend.

[ Web app ]    --->  [ Web BFF ]    ---\
[ iOS app ]    --->  [ iOS BFF ]    -----> [ Microservices ]
[ Android app] --->  [ Android BFF ] ---/

Cada BFF realiza três tarefas para seu cliente:

1. Agregar. Ele chama os microsserviços downstream que a tela precisa e combina suas respostas, para que o cliente faça uma única requisição em vez de cinco. Esta é a agregação de API aplicada a uma única experiência do usuário. Se você quiser a versão geral dessa ideia, veja nossa explicação sobre o padrão agregador de API.
2. Remodelar. Ele remove campos, renomeia itens para termos amigáveis ao cliente, nivela estruturas aninhadas e formata valores da maneira que a interface espera. O BFF móvel retorna payloads leves; o BFF de desktop retorna payloads ricos.
3. Traduzir. Ele lida com preocupações específicas do cliente, como estratégia de paginação, cache de resposta ajustado para aquele cliente e escolhas de protocolo, sem forçar essas decisões sobre os serviços compartilhados subjacentes.

Os microsserviços downstream permanecem de propósito geral e agnósticos ao frontend. Eles expõem capacidades limpas e reutilizáveis. O BFF é onde reside a modelagem específica do cliente, o que mantém essa lógica fora tanto dos microsserviços quanto do aplicativo cliente. Se você é novo na camada de serviço subjacente, nossa visão geral de microsserviços versus APIs e a transição de um monolito para microsserviços estabelece o contexto.

Um BFF por experiência do cliente

A orientação central de Newman é concisa: uma experiência, um BFF. Se seus aplicativos iOS e Android oferecem experiências significativamente diferentes, dê a cada um seu próprio BFF. Se um aplicativo web e um aplicativo móvel divergem, a mesma regra se aplica.

O objetivo da regra é manter cada BFF focado. No momento em que um único BFF tenta atender dois clientes com necessidades diferentes, ele começa a acumular lógica condicional ('se for móvel, retorne isso; se for web, retorne aquilo'), e você volta a ter um backend de propósito geral com todos os mesmos problemas de coordenação. Um BFF focado permanece pequeno, que é a propriedade que faz com que todo o padrão valha a pena.

Existe uma exceção sensata que o próprio Newman extrai do SoundCloud: quando uma equipe possui dois clientes semelhantes, como aplicativos iOS e Android que compartilham quase a mesma experiência, pode ser razoável compartilhar um único BFF móvel entre eles. O fator decisivo é a propriedade e a similaridade, não os nomes das plataformas. A regra é um padrão, não uma lei.

A propriedade pertence à equipe de frontend

Um BFF não é uma camada que a equipe de plataforma constrói e entrega. A equipe de frontend que é proprietária do cliente é proprietária de seu BFF. Esta é a segunda metade do que faz o padrão funcionar.

Quando a equipe de frontend é proprietária do BFF, ela controla seu ritmo de lançamento, escolhe sua linguagem e runtime, prioriza seu backlog e entrega mudanças para o cliente e seu serviço de apoio em conjunto. Uma mudança na UI que precisa de um novo endpoint agregado não exige a abertura de um ticket com uma equipe de backend separada e a espera para que seja liberado da fila dessa equipe. A equipe que sente a dor é proprietária da solução.

Essa autonomia é a verdadeira vitória. O BFF move o limite para que as decisões específicas do cliente sejam tomadas pelas pessoas responsáveis pelo cliente, que é exatamente onde o pensamento de conectividade orientada por API posiciona a camada de 'experiência'.

BFF vs. Gateway de API

Esta é a comparação em que a maioria das equipes tropeça, porque um BFF e um gateway de API parecem semelhantes em um diagrama. Ambos ficam entre clientes e serviços. Ambos podem rotear e agregar. Mas eles respondem a perguntas diferentes.

Um gateway de API é um ponto de entrada de propósito geral que lida com preocupações transversais para todo o tráfego: autenticação, limitação de taxa, roteamento, terminação TLS e log de requisições. É de propriedade de uma equipe de plataforma ou infraestrutura e é deliberadamente agnóstico ao cliente. Um gateway atende a todos da mesma forma.

Um BFF é o oposto. É específico do cliente por design, de propriedade de uma equipe de frontend, e seu único propósito é ser diferente para cada interface. É o lugar onde reside a modelagem do payload de um cliente, não um ponto de estrangulamento compartilhado.

Os dois não são rivais. Em um layout de produção comum, um gateway de API fica na frente, lidando com autenticação, limitação de taxa e monitoramento para todo o tráfego, e então roteia cada cliente para seu BFF dedicado atrás do gateway. A arquitetura de referência da Microsoft mostra exatamente isso: um gateway gerenciando preocupações transversais, com um BFF serverless por cliente atrás dele. Use o gateway para o que é igual entre os clientes e um BFF para o que é diferente. (Cobrimos a versão aprofundada desse contraste em um artigo separado; aqui é suficiente saber que eles se situam em camadas diferentes e atendem a necessidades distintas.)

Para o cenário de gateways circundantes, estas comparações publicadas ajudam: Gerenciamento de API vs Gateway de API, Gateway de API vs Balanceador de Carga e Service Mesh vs Gateway de API.

Quando usar um BFF

O padrão se justifica quando estas condições se aplicam:

• Você tem múltiplos clientes genuinamente diferentes. Web, mais mobile, mais uma integração com parceiros, cada um com necessidades de dados distintas. Quanto mais as experiências divergem, mais um BFF ajuda.
• Um backend compartilhado tornou-se um gargalo. Se cada mudança no frontend força uma negociação entre equipes, dividir a modelagem específica do cliente em BFFs por equipe remove o custo de coordenação.
• Você quer payloads otimizados para o cliente. O mobile precisa de respostas leves e cache agressivo; o desktop quer dados agregados ricos. Um BFF permite otimizar cada um sem comprometer.
• Uma linguagem se adequa melhor a um frontend. Uma equipe pode construir seu BFF no runtime que melhor se adapta ao seu cliente, independentemente do que os outros BFFs usam.

Quando não usar um BFF

O padrão não é gratuito, e há casos claros em que ele adiciona custo sem retorno:

• Você tem apenas um cliente. Com uma única interface, um BFF é apenas um salto extra. Construa um backend normal.
• Seus clientes fazem as mesmas requisições. Se web e mobile desejam dados quase idênticos no mesmo formato, BFFs separados duplicam o esforço sem benefício. Consolide em vez disso.
• GraphQL já resolve seu problema de modelagem. Com GraphQL, cada cliente consulta exatamente os campos de que precisa a partir de um único endpoint, o que cobre grande parte do que um BFF faz para a modelagem de payload. Se você tem uma camada GraphQL com resolvers específicos para o frontend, uma camada BFF separada muitas vezes não agrega valor. Veja o que é GraphQL para julgar se ele se encaixa antes de adicionar uma camada BFF.
• Um gateway mais microsserviços é suficiente. Para sistemas mais simples, um gateway de API na frente de microsserviços bem projetados pode entregar resultados aceitáveis sem uma camada dedicada por cliente.

As desvantagens honestas

Mesmo quando um BFF é a escolha certa, você assume custos reais. Entrar com os olhos abertos faz parte de usar bem o padrão.

• Duplicação de código. Esta é a principal contrapartida, e a documentação da Microsoft a aponta diretamente. Quando três BFFs precisam chamar a mesma verificação de autenticação ou formatar a mesma data da mesma maneira, essa lógica tende a ser escrita três vezes. Você está trocando duplicação por customização. A solução é disciplina: mantenha a lógica genuinamente compartilhada em bibliotecas que os BFFs importam, e reserve o próprio BFF para a modelagem específica do cliente. Leve as verdadeiras preocupações transversais (autenticação, limitação de taxa, monitoramento) para o gateway em vez de reimplementá-las por BFF.
• Mais serviços para operar. Cada BFF é outra unidade implantável com seu próprio ciclo de vida, pipeline, rotação de plantão e superfície de segurança. Mais serviços significam mais sobrecarga operacional.
• Um salto de rede extra. Os clientes não conversam mais diretamente com os serviços. O BFF adiciona um salto, e isso pode adicionar latência. Geralmente, é uma troca que vale a pena porque o BFF remove várias viagens de ida e volta do cliente, mas é um custo a ser medido, não assumido.
• Risco de o BFF ficar inchado. Se um BFF começa a atender múltiplos clientes ou a absorver lógica de negócio que pertence aos microsserviços, ele volta a se aproximar do backend de propósito geral do qual você estava tentando escapar. Mantenha-o enxuto.

Mantendo os contratos BFF sincronizados com Apidog

A parte difícil de executar BFFs na prática são os contratos. Cada BFF expõe sua própria API voltada para o cliente, e também depende dos contratos dos microsserviços subjacentes. Isso é um monte de interfaces móveis entre equipes que possuem diferentes camadas, e a divergência entre elas é onde surgem bugs e clientes quebrados.

É aqui que o Apidog se encaixa no fluxo de trabalho. Apidog é uma plataforma de design, teste, mocking e documentação de API, então o contrato de API de cada BFF tem um único lar contra o qual as equipes de frontend e backend podem trabalhar:

• Projete o contrato primeiro. Defina cada endpoint BFF e seu esquema de requisição e resposta no designer visual do Apidog com OpenAPI subjacente, para que o formato voltado para o cliente seja acordado antes que o código seja escrito. Esta é a abordagem de contrato-primeiro aplicada à camada BFF, e ela mantém o contrato de API explícito.
• Crie um mock antes que ele exista. A equipe de frontend pode começar a construir contra um mock inteligente do BFF do Apidog no dia em que o contrato for acordado, sem esperar que o BFF ou seus serviços downstream estejam prontos.
• Teste o contrato. Os testes automatizados e asserções do Apidog verificam se cada BFF retorna o payload agregado e remodelado que seu cliente espera, e eles se encaixam no CI para que uma mudança downstream que quebre uma resposta BFF seja detectada precocemente.
• Documente para ambos os lados. O Apidog gera automaticamente documentação interativa a partir do contrato, para que a equipe de frontend que lê a API do BFF e a equipe de backend que possui os serviços subjacentes compartilhem uma única fonte de verdade.

Para deixar claro o escopo: o Apidog não constrói, hospeda ou executa seu BFF, e não é um gateway de API. É onde você projeta, simula (mock), testa e documenta o contrato de API que cada BFF suporta, o que mantém as equipes de frontend e backend sincronizadas à medida que os BFFs evoluem. Tratar cada BFF como um produto com um contrato estável e bem documentado é o que torna o padrão sustentável.

FAQ

• Um BFF é um microsserviço? Um BFF é um serviço do lado do servidor, e em uma configuração de microsserviços geralmente funciona como um. Mas sua função é diferente de um microsserviço típico. Um microsserviço possui uma capacidade de negócio e permanece agnóstico ao cliente; um BFF possui a experiência de um cliente e existe para agregar e remodelar esses microsserviços para esse cliente. É um serviço de camada de experiência, não um serviço de capacidade de negócio.
• Quantos BFFs devo ter? O padrão é um por experiência de cliente distinta: um para web, um para iOS, um para Android, e assim por diante. Combine dois apenas quando uma única equipe possuir clientes com necessidades quase idênticas. Divida ainda mais quando um BFF começar a acumular lógica condicional por cliente.
• O GraphQL substitui o padrão BFF? Pode, para a parte de modelagem de payload. O GraphQL permite que cada cliente solicite exatamente os campos de que precisa de um único endpoint, o que cobre o excesso e a falta de dados (over-fetching e under-fetching) sem um backend por cliente. Se você tem GraphQL com resolvers específicos para o frontend, uma camada BFF separada muitas vezes agrega pouco. Os BFFs ainda ajudam quando você precisa de orquestração por cliente, tradução de protocolo ou escolhas de runtime que um servidor GraphQL compartilhado não pode fornecer facilmente.
• Posso usar um BFF e um gateway de API juntos? Sim, e é comum. O gateway de API lida com preocupações compartilhadas por todos os clientes, como autenticação, limitação de taxa e monitoramento, e roteia o tráfego para o BFF correto. Cada BFF lida com o que é específico para seu cliente. Eles se situam em camadas diferentes e realizam tarefas diferentes.
• Quem deve ser o proprietário do BFF? A equipe de frontend que possui o cliente. Essa propriedade é central para o padrão. Ela permite que a equipe entregue as mudanças de UI e os endpoints de apoio juntos, escolha seu próprio runtime e avance sem depender da fila de uma equipe de backend separada.
• Um BFF adiciona latência? Ele adiciona um salto de rede, o que tem um custo. Na prática, geralmente reduz a latência total do cliente, porque substitui várias viagens de ida e volta do cliente para o serviço por uma única requisição do cliente para o BFF e permite que o BFF chame os serviços em paralelo e próximos a eles. Meça isso para sua carga de trabalho em vez de assumir de qualquer maneira.