Backend for Frontend (BFF)

Como criar backends especializados por tipo de cliente para otimizar a experiência de cada plataforma sem acoplar os serviços internos.

Que problema resolve

Em uma arquitetura de microsserviços com um único API Gateway, todos os clientes (web, mobile, IoT, smart TV) consomem a mesma API. Mas cada cliente tem necessidades muito diferentes:

• Mobile: Precisa de respostas compactas (largura de banda limitada), dados agregados em poucas chamadas
• Web SPA: Consegue lidar com mais dados, precisa de paginação e filtros avançados
• IoT: Só precisa de um subconjunto mínimo de dados com protocolos leves

Problema com um único API Gateway:
  Mobile App ──► API Gateway ──► Microsserviços
  Web App    ──► (mesma API)
  IoT Device ──► (mesma API)
  
  A API retorna TODOS os campos para TODOS os clientes
  Mobile recebe dados que não precisa → desperdício de largura de banda
  Web não pode pedir dados extras sem afetar o mobile
  Cada mudança na API afeta todos os clientes

O resultado é uma API “one-size-fits-all” que não atende bem a nenhum cliente, ou uma API cheia de parâmetros condicionais (?platform=mobile&fields=name,price) que se torna difícil de manter.

Como funciona

O padrão BFF propõe criar um backend dedicado para cada tipo de cliente. Cada BFF é um serviço leve que atua como intermediário entre o seu cliente específico e os microsserviços internos.

Com BFF:
  Mobile App ──► BFF Mobile  ──┐
  Web App    ──► BFF Web     ──┤──► Microsserviços
  IoT Device ──► BFF IoT     ──┘
  
  Cada BFF adapta as respostas ao seu cliente
  Cada equipe de frontend controla o seu BFF
  Os microsserviços não mudam

Responsabilidades do BFF

Exemplo: endpoint de produto

Microsserviço Product Service retorna:
{
  "id": "P001",
  "name": "Laptop Pro",
  "description": "Laptop de alto rendimiento...",
  "specs": { "cpu": "i9", "ram": "32GB", "storage": "1TB" },
  "images": ["url1.jpg", "url2.jpg", "url3.jpg", "url4.jpg"],
  "reviews": [...50 reviews...],
  "relatedProducts": [...10 productos...],
  "inventory": { "warehouse1": 50, "warehouse2": 30 },
  "pricing": { "base": 1500, "discount": 10, "tax": 15 }
}

BFF Mobile retorna:
{
  "id": "P001",
  "name": "Laptop Pro",
  "image": "url1_thumb.jpg",
  "price": "$1,350",
  "rating": 4.5
}

BFF Web retorna:
{
  "id": "P001",
  "name": "Laptop Pro",
  "description": "Laptop de alto rendimiento...",
  "specs": { "cpu": "i9", "ram": "32GB", "storage": "1TB" },
  "images": ["url1.jpg", "url2.jpg", "url3.jpg", "url4.jpg"],
  "reviewSummary": { "average": 4.5, "count": 50 },
  "price": { "original": 1500, "final": 1350, "discount": "10%" },
  "relatedProducts": [...3 productos...]
}

Propriedade do BFF

Um princípio-chave do padrão é que a equipe de frontend é dona do seu BFF. Isso permite:

• A equipe mobile decide de quais dados precisa e como os estrutura
• As mudanças na UI não exigem coordenação com outras equipes
• Cada BFF evolui no ritmo do seu cliente

Vantagens

• Otimização por cliente: Cada plataforma recebe exatamente os dados de que precisa
• Autonomia das equipes: A equipe de frontend controla o seu backend sem depender de outras
• Evolução independente: Mudanças na API mobile não afetam a web nem o IoT
• Desempenho: Menos dados transferidos, menos chamadas a partir do cliente
• Simplicidade do cliente: O frontend consome uma API projetada especificamente para ele
• Segurança granular: Cada BFF pode implementar políticas de segurança específicas

Trade-offs / Desvantagens

• Duplicação de código: Lógica semelhante pode se repetir entre BFFs (mitigável com bibliotecas compartilhadas)
• Mais serviços para manter: Cada BFF é um serviço adicional que precisa de deploy e monitoramento
• Consistência: Diferentes BFFs podem retornar dados inconsistentes se não houver coordenação
• Complexidade organizacional: Requer equipes com capacidade full-stack (frontend + o seu BFF)
• Latência: Um salto adicional entre o cliente e os microsserviços
• Risco de BFF monolítico: Se o BFF crescer demais, transforma-se em um mini-monólito

Quando usar

• Múltiplos tipos de cliente com necessidades de dados muito diferentes
• Equipes de frontend que precisam de autonomia para evoluir a sua API
• Aplicações mobile onde a largura de banda e a quantidade de chamadas importam
• Quando um único API Gateway se torna complexo demais com lógica condicional por cliente
• Organizações com equipes dedicadas por plataforma (equipe mobile, equipe web)

Quando evitar

• Um único tipo de cliente (só web, ou só mobile)
• Clientes com necessidades de dados muito parecidas
• Equipes pequenas onde manter múltiplos BFFs não se justifica
• Quando um API Gateway com transformações simples é suficiente
• Protótipos ou MVPs onde a velocidade de desenvolvimento é prioridade

Tecnologias e implementações comuns

Relação com outros padrões

• API Gateway: O BFF é uma especialização do API Gateway por tipo de cliente
• Microsserviços: Os BFFs consomem microsserviços internos e os adaptam
• Anti-Corruption Layer: O BFF pode atuar como ACL entre o frontend e serviços legados
• Circuit Breaker: Cada BFF deve implementar circuit breaking em direção aos serviços que consome

Próximos passos

O BFF te dá controle granular sobre a experiência de cada cliente. Para entender como decompor os serviços que o BFF consome, explore o padrão Microsserviços. Para proteger a comunicação entre o BFF e serviços externos, revise o Anti-Corruption Layer.