Pular para o conteúdo
thiagoetipadrões

Contatos

apps/api/bff

114 · API & Integração · ≈ 6 min de estudo

Backend for Frontend (BFF)

Um backend por tipo de cliente, na frente dos serviços de domínio: numa única chamada, o BFF consulta os serviços em paralelo e devolve só o que aquela tela usa. O mobile recebe o mínimo para a home; a web recebe o painel completo. Use quando a tela precisa de dados de dois ou mais serviços e canais diferentes querem o mesmo dado em formatos diferentes.

passos
6
arquivos
5
teste
1
tecnologias
7
Infraestrutura realTypeScriptBunElysiaPostgreSQLJOSEPactDocker
CenárioRelaçõesComparar
Baixar cartão

Cenário

O banco digital tem um app e um internet banking. A home do app mostra primeiro nome, saldo disponível, os três últimos lançamentos e a próxima fatura; o painel web mostra a conta inteira, vinte lançamentos e todos os cartões. Os dados vêm de dois serviços — core bancário e cartões — que não sabem nada de telas. Se cartões cair, as telas saem sem a fatura, mas saem.

Planta

Sequência
8/8
par[em paralelo, timeout de 800 ms cada]GET /dashboard/0042-1 (sessao do usuario)1valida a sessao e a conta2GET /accounts/0042-1 (credencial de servico, x-correlation-id)3GET /accounts/0042-1/statement?limit=34GET /accounts/0042-1/cards5conta e extrato6fora do ar7200 home parcial, unavailable: [cards]8App mobileBFF mobilecore-bankingcards
8

8 passos — reproduza para seguir o fluxo

Como funciona

6 passos

Um backend sob medida por cliente.

Esconde cada passo: lembre antes de tocar para revelar.

Vocabulário compartilhado

x-correlation-id+3
Promise.allSettled+2
null+1
  1. 01

    bffAppCreate("mobile" | "web") cria um BFF por canal sobre o mesmo fan-out

  2. 02

    O BFF valida a sessão do usuário (JWT) e se a conta pedida é dele; o token do usuário não segue adiante — os serviços só aceitam a credencial de serviço

  3. 03

    dashboardFanOut chama os três endpoints com Promise.allSettled, timeout por chamada e o x-correlation-id do cliente

  4. 04

    Chamada que falha ou estoura o timeout vira null; a resposta lista as partes em unavailable. Só sem a conta não há tela (502)

  5. 05

    A projeção corta por canalMobile ~280 bytes, web ~1.100 bytes; o BFF só compõe — o saldo disponível vem calculado do core

  6. 06

    Contrato Pact por parCada BFF registra só os campos que lê do core, e o core real sobre PostgreSQL verifica os dois pactos

Trade-offs

O que se ganha, o que se paga

4 vantagenscada ganho tem um preço4 custos

Vantagens

  • Uma chamada por tela, payload do tamanho do canal

  • Serviço fora do ar deixa a tela parcial, não quebrada

  • Serviços de domínio sem conhecer telas

  • Contrato por BFF mostra quem lê cada campo

Custos

  • Mais um serviço por canal para operar

  • Tela parcial precisa ser tratada no front

  • Sem disciplina, regra de negócio migra para o BFF

  • Cada par consumidor-provedor é um pacto a manter

apps/api/bff

5 arquivos

src/

  • bff_channel.tsOs dois BFFs: sessão, fan-out e projeção por canal
  • downstream_bff.tsFan-out paralelo com timeout, credencial de serviço e correlation id
  • session_bff.tsSessão do usuário validada no BFF
  • service_core.tsServiços de domínio: core bancário e cartões
  • contract_core.test.tstestePactos de cada BFF e verificação do core real

Executar · com Docker

  1. ./docker.sh up# sobe PostgreSQL
  2. cp .env.example .env# variáveis de ambiente
  3. bun install# dependências
  4. bun run demo# roda o cenário
  5. bun run test# integração contra o serviço real
Requisitos
BunDocker
Sobe junto
PostgreSQL

Relações

Onde ele se encaixa

Mapa
  1. Backend for Frontend
  • Combina com6
  • Alternativa a1

Por que se relacionam

Combina com

Alternativa a

Teste rápido

Qual destes combina com Backend for Frontend?

Próximo projeto · API & IntegraçãoAnti-Corruption Layer
Esc

↑ ↓ navegarEnter abrir191 resultados