Backend for Frontend

Resumo

O Backend for Frontend (BFF) é um padrão arquitetural que cria uma camada de back-end dedicada por front-end (web, mobile, IoT). Essa camada atua como intermediária e adaptadora, agregando e transformando dados de múltiplos serviços para entregar apenas o necessário no formato ideal, reforçando eficiência, desacoplamento e qualidade de experiência, com custos adicionais de governança e manutenção.

Definição

O BFF é uma camada de back-end específica para cada front-end, responsável por orquestrar, agregar e transformar dados de microserviços e sistemas legados, expondo APIs sob medida que reduzem acoplamento e otimizam payloads e latência conforme as necessidades de cada canal.

Características principais

• Intermediação: Posiciona-se entre o front-end e os microserviços/sistemas legados, centralizando integração por canal.
• Personalização: Expõe contratos e modelos de dados ajustados ao contexto (web, mobile, IoT).
• Transformação: Agrega, filtra e normaliza dados, removendo campos irrelevantes para o cliente.
• Orquestração: Coordena chamadas a múltiplos serviços, consolidando respostas em um único payload.
• Autonomia: Permite que times por canal evoluam seus próprios BFFs com cadências independentes.

Benefícios

• Eficiência: Payloads menores, menos round-trips e latência reduzida por fluxo.
• Desacoplamento: Front-ends e serviços core evoluem com menor dependência direta.
• Experiência: Respostas adequadas a restrições de rede/dispositivo e necessidades do usuário.
• Organização: Ownership alinhado a times de produto/canal, acelerando entregas.

Desafios

• Governança: Requer padrões de contratos, versionamento, segurança e revisões arquiteturais.
• Duplicidade: Risco de replicar regras de negócio em múltiplos BFFs, exigindo clara separação de domínios.
• Manutenção: Aumenta número de componentes e superfícies de falha; demanda observabilidade robusta.
• Consistência: Necessita alinhamento entre BFFs para evitar divergência de modelos e comportamentos.

Critérios de uso

• Canais diversos: necessidades de dados significativamente distintas entre web, mobile e IoT.
• Complexidade no cliente: desejo de simplificar o front-end, movendo integração para o servidor.
• Performance contextual: otimização de latência e volume sob restrições específicas de rede/dispositivo.
• Autonomia de times: estrutura organizacional orientada a produto/canal com ownership claro e SLAs.

Relações

• Relacionado a: Microservices, Edge Services, API Gateway.
• Complementa: Arquiteturas orientadas a eventos, GraphQL Federation, Backend Composition.
• Difere de: API Gateway (prioriza roteamento, segurança e policies; não adapta payloads por canal).

Visualização

%%{init: {
  'theme': 'base',
  'themeVariables': {
    'background': '#0F1520',
    'mainBkg': '#253048',
    'nodeBorder': '#4A90D9',
    'primaryColor': '#253048',
    'primaryTextColor': '#E8EAF0',
    'primaryBorderColor': '#4A90D9',
    'lineColor': '#4A90D9',
    'textColor': '#E8EAF0',
    'edgeLabelBackground': '#253048',
    'clusterBkg': '#1E2A44',
    'clusterBorder': '#4A90D9',
    'titleColor': '#4A90D9',
    'fontSize': '14px'
  },
  'flowchart': {
    'nodeSpacing': 30,
    'rankSpacing': 30
  }
}}%%
flowchart LR

subgraph Frontends
    F1[Web]
    F2[Mobile]
    F3[IoT]
end

subgraph BFFs
    B1[BFF Web]
    B2[BFF Mobile]
    B3[BFF IoT]
end

subgraph Core Services
    S1[Users]
    S2[Products]
    S3[Orders]
    S4[Notifications]
    S5[Inventory]
    S6[Auth]
end

F1 --> B1
F2 --> B2
F3 --> B3

B1 --> S1
B1 --> S2
B1 --> S3
B1 --> S5
B1 --> S6

B2 --> S1
B2 --> S2
B2 --> S4
B2 --> S6

B3 --> S2
B3 --> S5
B3 --> S6