Em arquiteturas tradicionais, é comum expor uma única API REST ou GraphQL centralizada (uma General-Purpose API) para atender a todas as aplicações clientes do sistema. Essa API genérica serve tanto o aplicativo mobile quanto a aplicação web desktop, painéis administrativos e dispositivos IoT, retornando a mesma estrutura de dados para qualquer consumidor.
Conforme a aplicação cresce, as necessidades de interface de cada dispositivo começam a divergir drasticamente. Aplicativos móveis exigem dados compactados e menos chamadas de rede devido a conexões 3G/4G/5G instáveis e telas menores. Já aplicações web desktop possuem espaço de sobra em tela, conexões de alta velocidade e exigem visões agregadas e detalhadas. Tentar atender a todos esses cenários com um único ponto de entrada gera degradação de performance e acoplamento excessivo.
A Abordagem Tradicional: API Gateway Genérico Único
A tentativa convencional de resolver a comunicação entre clientes e microsserviços baseou-se no uso de um API Gateway Monolítico. Nesse modelo, uma única camada de fachada recebe todas as requisições, faz o roteamento para os microsserviços internos e devolve respostas padronizadas para qualquer tipo de dispositivo.
Limitações do API Gateway Genérico
- Over-fetching e Under-fetching de Dados: Dispositivos móveis recebem dezenas de campos desnecessários para a tela atual (over-fetching) ou precisam fazer múltiplas chamadas consecutivas para montar uma única interface (under-fetching);
- Acoplamento de Times: Mudanças na API para atender uma nova funcionalidade do aplicativo mobile correm o risco de quebrar a aplicação web ou exigir alinhamentos entre múltiplos times;
- Gargalo de Implantação: O API Gateway central vira um ponto único de alteração, onde qualquer novo deploy exige coordenação global e aumenta o risco de regressões;
- Lógica de Interface no Backend Central: Validações específicas de telas ou formatação de dados para visualização acabam poluindo os microsserviços de domínio.
A Abordagem Moderna: Backend For Frontend (BFF) Pattern
O padrão Backend For Frontend (BFF) resolve esse problema criando camadas de backend customizadas e dedicadas para cada tipo de interface de usuário. Em vez de uma API única para todos, cria-se um BFF específico para o app iOS/Android, outro para a aplicação Web Desktop e, se necessário, outro para integrações de parceiros.
Cada camada BFF é desenhada, mantida e frequentemente implantada pelo mesmo time responsável pela interface do usuário (Frontend) correspondente.
Como Funciona o Mecanismo
- Requisição Otimizada: O aplicativo mobile faz uma única chamada HTTP para o seu Mobile-BFF, solicitando apenas o estritamente necessário para montar a tela atual.
- Orquestração Interna: O Mobile-BFF faz as chamadas em paralelo para os microsserviços de catálogo, preços e perfil na rede interna de alta velocidade.
- Formatação e Agregação: O BFF filtra os campos desnecessários, formata os dados para o padrão do aplicativo e devolve um único JSON enxuto e pronto para ser renderizado.
- Isolamento de Mudanças: Atualizações na interface da Web alteram apenas o Web-BFF, sem impactar em nada o ecossistema móvel.
Estratégias de Implementação do BFF
1. BFF por Tipo de Dispositivo (Mobile vs. Web)
Cria-se um BFF unificado para plataformas móveis (iOS/Android) e outro para navegadores web. É a abordagem mais comum e oferece um excelente equilíbrio entre desempenho e manutenção.
- Vantagens: Atende bem às diferenças de largura de banda e tamanho de tela sem multiplicar excessivamente o número de aplicações.
- Desvantagens: Se o app iOS e Android divergirem muito em funcionalidades, o Mobile-BFF pode começar a acumular condicionais internas.
2. BFF por Aplicação/Plataforma Específica
Cada aplicação do ecossistema possui seu próprio backend dedicado (ex: iOS-BFF, Android-BFF, Admin-Web-BFF).
- Vantagens: Autonomia total para os times de frontend e otimização máxima para o ciclo de vida daquela plataforma.
- Desvantagens: Risco de duplicação de lógica de agregação entre os diferentes BFFs se não houver um bom alinhamento de arquitetura.
Quando Utilizar Cada Abordagem?
- Utilize uma API Genérica (API Gateway Único) quando: O sistema for pequeno, possuir apenas uma aplicação web consumindo os dados ou os requisitos de dados entre mobile e web forem idênticos.
- Utilize BFF por Tipo de Dispositivo quando: O aplicativo móvel sofrer com lentidão devido a múltiplas chamadas de rede (chattiness) e a equipe desejar otimizar o consumo de dados móveis sem inflar as APIs internas.
- Utilize BFF por Aplicação Específica quando: Existirem times independentes cuidando de cada plataforma (iOS, Android, Web), com ciclos de release distintos e interfaces significativamente diferentes.
Na prática, o padrão Backend For Frontend (BFF) tornou-se fundamental para grandes produtos digitais, permitindo que times de frontend tenham autonomia total para evoluir suas interfaces com altíssima performance de rede.
