API Gateway vs BFF para clientes web e mobile: prós e contras

O problema: um backend, muitos clientes e necessidades diferentes

Um ponto de partida comum é simples: um backend expõe um conjunto de endpoints, e tanto o app web quanto o mobile os consomem. Parece eficiente porque existe um único lugar para adicionar recursos, corrigir bugs e aplicar regras.

Aí vem a realidade. A interface web costuma precisar de telas densas, filtros, exportações e ações administrativas. O mobile geralmente precisa de menos campos, telas mais rápidas, fluxos tolerantes a offline e cuidado com bateria e dados. Mesmo quando a funcionalidade é “a mesma”, a melhor forma da API para cada cliente raramente é idêntica.

Com o tempo, os endpoints divergem. O time web adiciona campos extras para uma nova visão em tabela. O mobile pede para remover payloads pesados e combinar várias chamadas em uma só. Alguém adiciona um parâmetro “só para iOS”. Outro usa um endpoint interno de admin no app público porque “já existia”. O que começou como uma API limpa vira uma coleção de compromissos.

Os riscos aparecem rápido:

• Quebras quando um cliente lança mais rápido que o outro
• Apps mais lentos por payloads grandes ou muitas idas e voltas
• Código backend mais complexo à medida que cada endpoint tenta servir todo mundo
• Exposição acidental de dados quando campos ou ações internas vazam para APIs públicas
• Versionamento doloroso porque “pequenas mudanças” não são pequenas para clientes antigos

Essa é a tensão central na discussão API gateway vs BFF. Você quer APIs públicas estáveis que mobile e web possam confiar, ao mesmo tempo em que dá a cada cliente espaço para evoluir no seu ritmo.

API gateway e BFF: o que são (e o que não são)

Um API gateway é a porta de entrada das suas APIs. Os clientes chamam o gateway, que roteia as requisições para o serviço certo. Ele costuma cuidar de preocupações compartilhadas que você não quer repetir, como checagem de autenticação, limites de taxa, logging de requisições e modelagem básica de requests.

Um backend-for-frontend (BFF) é um backend pequeno construído para um cliente específico ou grupo de clientes, como “web” e “mobile”. O cliente chama seu BFF, e o BFF chama os serviços subjacentes. A ideia chave é foco: o BFF fala a linguagem do cliente (telas, fluxos e payloads), mesmo que os serviços centrais permaneçam mais genéricos.

O que esses padrões não são: não substituem bons serviços de domínio ou um modelo de dados limpo. Seus serviços centrais, bancos de dados e regras de negócio devem continuar sendo a fonte da verdade. Um gateway ou BFF não deve virar um monólito de lógica de negócio que, aos poucos, se transforma no seu backend real.

Uma forma simples de distingui-los:

• Gateway: um ponto de entrada, preocupações compartilhadas, roteamento e proteção
• BFF: APIs específicas para cliente que reduzem trabalho no cliente e escondem complexidade interna

Você pode combiná-los. Um arranjo comum é ter o gateway na borda pública e BFFs separados atrás dele para web e mobile. O gateway cuida de segurança externa e regras de tráfego, enquanto cada BFF molda endpoints e respostas para seu cliente.

Como o caminho da requisição muda em cada padrão

A maior diferença entre um API gateway e um BFF é onde você coloca a lógica da “porta de entrada”: roteamento, checagens de autenticação e modelagem de resposta.

Com um API gateway, o cliente normalmente fala com um ponto de entrada compartilhado. O gateway encaminha requisições para serviços internos, fazendo tarefas básicas como validação de token, limites de taxa e roteamento por caminho.

Com um BFF, cada tipo de cliente (web, iOS, Android) chama um backend construído especificamente para ele. Esse BFF então chama serviços internos e retorna uma resposta adaptada às telas e restrições do cliente.

Um jeito simples de imaginar o caminho da requisição:

• Caminho com API gateway: Cliente -> Gateway -> Serviço(s) -> Resposta
• Caminho com BFF: Cliente -> BFF (web ou mobile) -> Serviço(s) -> Resposta

A propriedade costuma mudar também. Um time de plataforma ou infraestrutura normalmente é dono do gateway porque ele afeta todos os times e serviços. Um time de feature frequentemente é dono do BFF porque ele acompanha a UI e seu ciclo de release.

A autenticação costuma fluir assim: o cliente envia um token, a camada de borda (gateway ou BFF) o valida ou o encaminha para um serviço de auth, e então passa detalhes da identidade (id do usuário, papéis) para os serviços downstream. A diferença é onde você aplica regras por cliente. No gateway, as políticas costumam ser genéricas e consistentes entre clientes. No BFF, você pode adicionar moldagem específica do cliente, como retornar um payload menor para mobile ou combinar várias chamadas em uma só resposta em redes lentas.

Esse passo de moldagem é onde BFFs brilham, mas também significa mais partes móveis para implantar e manter consistentes.

Separando endpoints públicos vs internos com segurança

Um endpoint público é qualquer rota de API que seu app web, app mobile, parceiros ou terceiros possam alcançar. Trate-o como hostil por padrão, porque você não controla a rede por onde ele trafega nem o código do cliente que o chama.

Um endpoint interno é destinado a tráfego service-to-service dentro do seu sistema. Ele pode mudar mais rápido, assumir mais contexto e expor dados mais ricos, mas nunca deve ser alcançável diretamente pela internet pública.

Com um API gateway, a separação costuma ser física e fácil de raciocinar: apenas o gateway é exposto, e ele decide quais rotas externas existem. Tudo atrás dele permanece privado. Você pode manter APIs de serviço internas expressivas, enquanto o gateway aplica uma superfície menor e mais segura.

Com o padrão BFF, a separação é mais sobre fronteiras de produto. Cada cliente (web, iOS, Android) fala apenas com seu BFF, e o BFF chama serviços internos. Isso permite esconder complexidade interna: o BFF pode chamar três serviços, mesclar resultados e expor uma resposta simples que corresponde ao que o cliente realmente precisa.

A separação só é segura se você adicionar controles práticos:

• Autorização específica: papéis e escopos por rota, não um único interruptor "logado"
• Limites de taxa por usuário, token e IP para endpoints públicos
• Filtragem de payloads: retorne apenas o que o cliente precisa, remova IDs internos, informações de debug e campos só para admin
• Allowlists claras: quais endpoints são públicos e quais são apenas internos

Exemplo: um app mobile precisa de uma tela “Meus Pedidos”. O BFF pode expor /orders com apenas status do pedido e totais, enquanto o serviço interno de pedidos mantém detalhes do custo e flags de fraude privados.

Versionamento: o que fica mais fácil e o que fica mais difícil

A dor do versionamento geralmente aparece quando web e mobile se movem em velocidades diferentes. Um time web pode lançar e reverter em horas. Um app mobile pode levar dias ou semanas por causa da revisão das lojas e de usuários que não atualizam. Essa lacuna é onde a decisão API gateway vs BFF vira prática.

Com um API gateway, você pode colocar versionamento na porta de entrada (por exemplo, /v1/..., /v2/...). Isso é fácil de explicar e rotear. A desvantagem é que o gateway pode se transformar em um museu de versões se muitos clientes e parceiros manterem versões antigas. Você acaba suportando formas antigas dos mesmos dados por mais tempo.

Com um BFF, o versionamento costuma ser “por cliente”. O BFF mobile pode permanecer em um contrato mais antigo enquanto o BFF web avança, mesmo que ambos falem com os mesmos serviços internos. Isso reduz a pressão de manter versões públicas vivas para sempre. O tradeoff é mais partes móveis: agora você tem mais decisões de versão para gerenciar e implantar.

Versionar dentro dos serviços também funciona, mas empurra mudanças dirigidas pelo cliente para camadas profundas do sistema. Também pode tornar o código interno mais difícil de ler porque a lógica do serviço começa a ramificar conforme versões dos clientes.

Mudanças não-break são suas aliadas: adicionar campos opcionais, criar novos endpoints ou aceitar campos extras de input. Mudanças breaking incluem renomear um campo, mudar um tipo (string para number) ou remover um endpoint.

Deprecar funciona melhor quando planejado:

• Defina uma data clara de encerramento e comunique com antecedência
• Monitore o uso da versão antiga (logs, métricas) e procure por clientes restantes
• Lance atualizações nos clientes primeiro (especialmente mobile), depois remova o caminho antigo
• Retorne uma mensagem de erro clara quando a versão antiga for bloqueada

Desempenho: latência, tamanho de payload e número de chamadas

O desempenho em uma arquitetura gateway vs BFF é, na maior parte, uma troca: um salto interno a mais no sistema versus menos saltos pela rede do cliente. A opção mais rápida costuma ser a que reduz o tempo de rede do cliente, mesmo que adicione um pequeno passo no servidor.

Um BFF costuma ganhar quando o cliente faria muitas chamadas. Em vez de web e mobile chamarem cinco endpoints e montar resultados no dispositivo, o BFF pode buscar tudo no servidor e devolver uma resposta única. Isso costuma reduzir a latência total no mobile, porque redes celulares adicionam atraso a cada requisição.

Ganhas comuns com gateway ou BFF:

• Agregação: combine dados de vários serviços em uma resposta
• Cache mais inteligente: cache na borda ou no BFF para telas de leitura intensiva
• Payloads menores: retorne apenas campos que a tela precisa
• Menos round trips: reduza comportamento chatty do cliente
• Compressão e timeouts consistentes: aplique defaults em um só lugar

Mas o padrão também pode prejudicar. Cada camada adiciona trabalho de CPU e mais pontos de espera. Se você duplicar a mesma lógica de agregação para web e mobile, pode dobrar o trabalho e gerar comportamento inconsistente. Over-fetching é outra perda comum: um endpoint genérico que tenta servir todas as telas pode retornar payloads grandes que desperdiçam tempo e banda.

Realidades mobile tornam esses tradeoffs mais agudos. Redes instáveis significam retries e timeouts normais, e cada chamada extra consome bateria. Cold starts também importam: se o app precisa de várias requisições antes da primeira tela ficar usável, o usuário sente.

Uma regra prática: otimize primeiro para menos requisições do cliente, depois otimize o salto extra.

Forma rápida de julgar um design

Se uma tela precisa de mais de 2–3 chamadas sequenciais, considere agregação. Se respostas são grandes e a maior parte não é usada, avalie dividir endpoints ou usar um BFF por cliente.

Operações: deploy, monitoramento e escalabilidade

Na comparação API gateway vs BFF, a grande questão operacional é quantas partes móveis você está disposto a rodar e suportar. Um gateway costuma virar infraestrutura compartilhada para muitos times e clientes. BFFs são serviços menores, mas você pode acabar com um por client (web, iOS, Android, parceiro), o que aumenta carga de deploy e on-call.

Em testes e releases, o gateway pode ser mais seguro quando você precisa principalmente de roteamento, auth e limites de taxa. Mudanças são centralizadas, então um erro pode afetar todos. BFFs reduzem o blast radius porque uma mudança só para web é deployada no web BFF, não no mobile. O tradeoff é mais pipelines para manter e mais versões simultâneas em produção.

Para observabilidade, você precisa enxergar uma requisição de usuário através das camadas, especialmente quando uma chamada mobile dispara várias chamadas backend.

• Use um ID de correlação e passe-o por gateway, BFF e logs backend
• Capture traces para identificar onde o tempo é gasto (gateway, BFF, serviço downstream)
• Mantenha logs estruturados (cliente, endpoint, status code, latência, tamanho do payload)
• Monitore algumas métricas-chave por endpoint: taxa de erro, p95 de latência, throughput

Escalar muda o formato também. Um gateway é um ponto de estrangulamento compartilhado: ele precisa lidar com picos e endpoints quentes sem virar gargalo. BFFs permitem escalar por cliente, o que ajuda quando o tráfego web sobe nas horas comerciais enquanto o mobile permanece estável.

Em incidentes, falhas podem “mover” dependendo do padrão. No gateway, problemas costumam aparecer como 5xx generalizados ou falhas de auth. Com BFFs, questões podem se isolar a uma feature de um cliente. Tenha runbooks claros sobre onde olhar primeiro e mantenha comportamentos de fallback simples (por exemplo, retornar uma resposta reduzida ao invés de timeout).

Como escolher: um processo de decisão simples passo a passo

Escolher entre API gateway e BFF é menos teoria e mais sobre o que seus clientes precisam no dia a dia.

Fluxo prático de decisão

1. Comece pelos clientes, não pelos servidores. Liste todos os clientes que você suporta (app web, iOS, Android, API de parceiro, admin interno) e anote o que cada tela chave precisa. Se a mesma visão “Detalhes do Cliente” precisa de campos e padrões de chamadas diferentes entre clientes, isso é um sinal forte para moldagem específica por cliente.

2. Mapeie o que você tem hoje. Marque endpoints compartilhados (operações de domínio como pedidos, pagamentos, usuários) versus pieces moldadas para apresentação (resumo do dashboard, payload combinado de “home screen”). Partes compartilhadas pertencem ao backend central. Peças moldadas para apresentação costumam caber melhor num BFF.

3. Decida onde a moldagem e regras devem viver. Se você precisa principalmente de roteamento, auth, limites de taxa, cache e exposição segura de endpoints, o gateway é o local natural. Se você precisa de composição real (chamar vários serviços, transformar seis chamadas em uma, payloads diferentes por app), coloque essa lógica no código do BFF para manter testabilidade e legibilidade.

4. Escolha uma regra de versionamento e depreciação que você realmente consiga seguir. Por exemplo: “Sem breaking changes sem nova versão, e todo campo depreciado permanece por 90 dias.” Com apenas gateway, você pode acabar versionando a superfície pública e traduzindo por trás. Com BFFs, frequentemente mantém-se as APIs centrais estáveis e versiona só os endpoints do BFF por cliente.

5. Planeje rollout e meça. Antes de mudar, capture métricas base: p95 de latência, número de chamadas por tela, tamanhos de payload e taxa de erro. Lance para uma pequena porcentagem primeiro, compare antes/depois e então expanda.

Um exemplo simples: se seu mobile lança mensalmente mas seu portal web entrega mudanças diariamente, um pequeno BFF mobile pode proteger o app de mudanças frequentes no backend enquanto o cliente web segue veloz.

Exemplo: portal web + app mobile com velocidades de release diferentes

Imagine uma empresa com portal web para clientes e um app de campo no mobile. Ambos precisam dos mesmos dados centrais: clientes, ordens, faturas e mensagens. O portal muda semanalmente. O app mobile atualiza mais devagar por conta da loja e precisa funcionar com sinal fraco.

A dor aparece rápido. Usuários mobile querem respostas compactas, menos chamadas e fluxos que suportem offline (por exemplo, baixar tarefas do dia e sincronizar depois). O portal web faz mais chamadas e carrega telas mais ricas porque está sempre online e é mais fácil de atualizar.

Opção A: gateway em frente a serviços estáveis

A escolha gateway-first mantém seus serviços backend quase intactos. O gateway cuida de autenticação, roteamento e pequenos ajustes como headers, limites de taxa e mapeamento simples de campos.

Versionamento fica mais no nível das APIs de serviço. Isso pode ser bom: menos partes móveis. Mas também significa que mudanças específicas para mobile podem forçar versões amplas como /v2 porque os endpoints subjacentes são compartilhados.

A exposição de endpoints fica clara se você tratar o gateway como única porta pública. Endpoints internos ficam por trás dele, mas é preciso ser rigoroso sobre o que o gateway pode alcançar e o que publica.

Opção B: um BFF mobile que fala “mobile”

Com um BFF mobile, o app conversa com endpoints desenhados para telas mobile e fluxos de sync. O BFF pode agregar dados (detalhes da tarefa + cliente + última mensagem), enxugar campos e retornar um payload único que bate com o que o app precisa.

O que muda:

• Versionamento fica mais fácil por cliente: você versiona o BFF mobile sem forçar o portal web a mudar
• Desempenho costuma melhorar para mobile: menos round trips e respostas menores
• Separação pública vs interna fica mais nítida: o BFF é público, mas chama serviços internos que nunca precisam ser expostos

Erros comuns e armadilhas para evitar

A maior armadilha é transformar o gateway em um mini-backend. Gateways são excelentes em roteamento, auth, limites de taxa e modelagem simples. Ao empacotar regras de negócio nele, você cria lógica oculta difícil de testar, depurar e fácil de quebrar em uma mudança de configuração.

BFFs podem falhar no sentido oposto: times criam um BFF por tela ou feature, e a manutenção explode. Um BFF deve normalmente mapear para um tipo de cliente (web, iOS, Android) ou uma área de produto clara, não para cada view da UI. Caso contrário, você duplica regras em dez lugares e o versionamento vira trabalho integral.

Erros de versionamento vêm de extremos. Versionar tudo no dia zero congela a API cedo demais e mantém variantes antigas para sempre. Nunca versionar leva a quebras não intencionais. Uma regra simples funciona bem: não versionar para pequenas mudanças aditivas; versionar quando remover ou mudar significado.

Expor serviços internos diretamente (mesmo “temporariamente”) transforma qualquer mudança interna em um potencial incidente de segurança ou disponibilidade. Mantenha fronteiras claras: somente o gateway ou BFF deve ser público; serviços internos devem ficar privados.

Problemas de performance quase sempre são autoinfligidos: payloads enormes, muitas requisições e sem orçamento para latência. Ex.: mobile só precisa do status do pedido e totais, mas recebe o objeto completo com itens e campos de auditoria, deixando cada requisição lenta na rede celular.

Sinais de alerta para monitorar:

• Configs do gateway referenciam conceitos de negócio como “eligibilidade de reembolso” ou “regras VIP”
• BFFs proliferam mais rápido que os clientes que servem
• Você não consegue explicar sua estratégia de versionamento em uma frase
• Endpoints internos são acessíveis da internet pública
• Respostas crescem sem parar porque “pode ser útil depois”

Checklist rápido e próximos passos

Se estiver em dúvida entre API gateway vs BFF, foque no que vai quebrar primeiro na prática: releases, payloads e limites de segurança.

Checklist rápido

Se você responder “não” a várias destas, sua arquitetura atual tende a prejudicar à medida que os clientes crescem:

• Você consegue mudar um serviço backend sem forçar todo cliente a atualizar na mesma semana?
• Existe uma fronteira clara entre endpoints públicos (seguros para a internet) e internos (apenas para sistemas confiáveis)?
• Web e mobile recebem somente o que precisam (não um grande response “cozinha inteira”)?
• Você pode fazer rollout gradual (pequena porcentagem primeiro) e ver erros, latência e tráfego incomum rapidamente?
• Você sabe quem é dono do contrato de cada endpoint e quem aprova breaking changes?

Próximos passos

Transforme as respostas em um plano. O objetivo não é arquitetura perfeita, mas menos surpresas ao enviar mudanças.

Escreva o contrato de API em linguagem simples (inputs, outputs, códigos de erro, o que pode mudar). Escolha um modelo de propriedade: quem é dono das necessidades do cliente (web/mobile) e quem é dono dos serviços centrais. Decida onde fica o versionamento (por cliente ou centralmente) e estabeleça uma regra de depreciação que você vá cumprir.

Adicione monitoramento básico antes de grandes refatores: taxa de requisições, p95 de latência, taxa de erro e os endpoints com maior payload. Prototipe os fluxos de cliente mais arriscados primeiro.

Se você está construindo com AppMaster (appmaster.io), uma abordagem prática é manter lógica de negócio e modelos de dados no backend gerado, e só adicionar uma camada fina de gateway ou BFF quando um cliente realmente precisar de moldagem de payload ou isolamento de release.

Se o checklist parecer difícil de responder, encare isso como um sinal para simplificar contratos e apertar a separação público vs interno antes de adicionar mais endpoints.