Backend por consumer
1. Introdução¶
Nesta opção, cada canal de consumo (portal do cliente, portal do corretor e superapp) passa a consumir um BFF dedicado, ou seja, uma API pensada especificamente para a experiência e necessidade daquele canal:
- BFF Cliente (portal do cliente)
- BFF Corretor (portal do corretor)
- BFF Superapp (aplicativo)
WhatsApp (webhooks) e parceiros normalmente ficam fora desse modelo (ou ganham entradas dedicadas próprias), porque são integrações com natureza diferente de um frontend tradicional.
O BFF não substitui a regra de negócio principal. Ele chama um core interno (API interna de domínio), que concentra regras, validações e persistência. Na transição, esse core pode ser a API atual, atrás de um “adapter” (camada de compatibilidade), até a arquitetura nova amadurecer.
2. Visão estratégica¶
2.1. O que esta opção resolve¶
- Segurança por superfície: cada canal só enxerga e acessa o BFF dele. Mesmo que exista um endpoint “parecido” em outro canal, ele não está na mesma superfície exposta.
- Contratos separados por canal: cada BFF define o contrato ideal para o seu frontend, evitando o “contrato Frankenstein” tentando servir todos.
- Flexibilidade sem entortar o core: o BFF pode adaptar payload, orquestrar chamadas e montar respostas específicas, sem poluir o core com regras de apresentação.
- Evolução independente: é possível evoluir o superapp rapidamente sem quebrar os portais, e vice-versa.
2.2. O que esta opção não resolve sozinha¶
- Regras de negócio continuam no core: se o core não validar vínculo e permissões corretamente, o BFF não “salva” segurança por si só.
- Complexidade operacional aumenta: são mais serviços para operar e monitorar (BFF Cliente, BFF Corretor, BFF Superapp, e possivelmente BFF IA).
- Risco de duplicação: se o time colocar regra de negócio no BFF, ele vira um “mini-sistema” e começa a duplicar lógica entre canais.
3. Visão de negócio¶
3.1. Benefícios¶
- Experiência melhor por canal: cada frontend recebe exatamente o que precisa (campos, formatos, ordem, agregações), reduzindo “gambiarras” no front.
- Menos impacto de mudanças: mudanças no contrato do superapp não precisam afetar portais e parceiros.
- Canal mais seguro e controlado: as permissões e limites podem ser calibrados de forma diferente por canal (ex.: superapp por device, corretor por carteira, cliente por CPF).
- Facilita o lançamento do superapp: o superapp pode ter um BFF que já nasce “certo” e, internamente, fala com o legado (adapter) enquanto a migração acontece.
3.2. Pontos de atenção para o negócio¶
- É necessário definir claramente:
- quais funcionalidades são responsabilidade do BFF (orquestração e adaptação),
- quais são responsabilidade do core (regras de negócio e segurança),
- como versionar contratos do superapp sem impactar portais.
- Parceiros e webhooks precisam de contratos dedicados e mais rígidos; não devem “entrar pelo mesmo caminho” dos frontends.
4. Fluxo de funcionamento¶
%%{init:{
"theme":"neutral",
"fontSize":22,
"flowchart":{"curve":"basis","htmlLabels":true,"nodeSpacing":50,"rankSpacing":70}
}}%%
flowchart TB
A["Consumidor faz requisicao"]:::ui_input --> B{Canal do consumidor}:::decision
B -- Cliente --> C["BFF Cliente<br/>api dedicada ao portal cliente"]:::ui_input
B -- Corretor --> D["BFF Corretor<br/>api dedicada ao portal corretor"]:::ui_input
B -- Superapp --> E["BFF Superapp<br/>api dedicada ao app"]:::ui_input
B -- Parceiros --> F["API Parceiros<br/>contrato externo controlado"]:::ui_input
B -- Webhooks --> G["Servico Webhooks<br/>entrada publica minima"]:::ui_input
B -- IA --> H["BFF IA<br/>api para agentes e automacoes"]:::ui_input
C --> I["Autenticacao do canal<br/>token sessao cors"]:::ui_input
D --> I
E --> I
H --> I
I --> J{Token valido}:::decision
J -- Nao --> K["Negar acesso<br/>401 ou 403"]:::ui_button
J -- Sim --> L["Orquestrar fluxo do canal<br/>compor telas e passos"]:::ui_input
L --> M["Chamar Core Interno<br/>endpoints internos"]:::endpoint_post
M --> N["Core aplica regras de negocio<br/>vinculos validacoes"]:::endpoint_post
N --> O["BFF adapta payload do canal<br/>formatos e campos"]:::ui_input
O --> P["Registrar auditoria e metricas<br/>por canal e usuario"]:::ui_input
P --> Q["Resposta para consumidor<br/>payload do canal"]:::endpoint_get
F --> R["Politicas parceiros<br/>chave quota limites"]:::ui_input
R --> S{Acesso parceiro ok}:::decision
S -- Nao --> K
S -- Sim --> T["Operacoes do contrato<br/>subset de recursos"]:::endpoint_post
T --> N
N --> P
G --> U["Validar assinatura e origem<br/>idempotencia"]:::ui_input
U --> V{Webhook valido}:::decision
V -- Nao --> K
V -- Sim --> W["Transformar evento em comando interno<br/>sem expor core"]:::endpoint_post
W --> N
N --> P
classDef endpoint_get fill:#e0f2fe,stroke:#0284c7,color:#0f172a,stroke-width:1px;
classDef endpoint_post fill:#dcfce7,stroke:#16a34a,color:#052e16,stroke-width:1px;
classDef endpoint_put fill:#fef9c3,stroke:#a16207,color:#3b2f0b,stroke-width:1px;
classDef endpoint_delete fill:#fee2e2,stroke:#ef4444,color:#7f1d1d,stroke-width:1px;
classDef ui_input fill:#eef2ff,stroke:#6366f1,color:#111827,stroke-width:1px;
classDef ui_button fill:#ede9fe,stroke:#7c3aed,color:#1f2937,stroke-width:1px;
classDef decision fill:#fff7ed,stroke:#f59e0b,color:#78350f,stroke-width:1px;
5. Manutenção e longo prazo¶
5.1. Manutenção do código¶
- Separação saudável de responsabilidades:
- BFF: orquestração, composição de respostas, adaptação de contrato, “colagem” de chamadas.
- Core: regras de negócio, persistência, validações de vínculo, consistência, integrações críticas.
- Redução de “if canal”: o core tende a ficar mais limpo, porque quem conhece “formato do canal” é o BFF.
- Risco principal (a evitar): BFF virar mini-sistema.
- Isso acontece quando regras de negócio começam a ser duplicadas no BFF.
- Para evitar, é essencial padronizar: “regra de negócio mora no core”.
Boas práticas para manter sustentável: - Contratos por canal com versionamento claro (ex.: v1, v2) sem quebrar portais. - Bibliotecas compartilhadas de autenticação, logging e métricas (para evitar divergência entre BFFs). - Testes de contrato (contract tests) entre BFF e core (garantindo compatibilidade). - Observabilidade distribuída (correlação de logs por request id).
5.2. Escalabilidade¶
- Escala por canal: se o superapp crescer muito, dá para escalar o BFF Superapp sem afetar BFF Cliente/Corretor.
- Proteções específicas por canal:
- limites por device/token no superapp;
- limites por carteira e operações no corretor;
- limites por CPF/usuário no cliente.
- Risco de latência: mais hops (cliente -> BFF -> core). Para mitigar:
- caching no BFF para leitura;
- composição eficiente (evitar várias chamadas ao core por tela);
- endpoints internos no core mais “prontos” para o BFF.
6. Adaptação ao legado do PASI¶
Esta opção se encaixa bem quando existe legado forte e múltiplos consumidores já em produção, porque permite criar a nova experiência por canal sem exigir que o core novo esteja 100% pronto desde o dia 1.
6.1. Caminho de adaptação recomendado¶
- Criar BFF Superapp primeiro (por urgência de lançamento)
- Superapp consome somente o BFF Superapp.
- O BFF chama o core interno, que pode ser o legado inicialmente (via adapter).
- Encapsular endpoints legados atrás do adapter
- O adapter “traduza” chamadas antigas em um contrato interno controlado.
- Ajuda a remover dependências diretas do superapp com o legado.
- Endurecer autenticação e autorização no core
- Mesmo com BFF, o core precisa validar vínculo e permissões de forma consistente.
- Evoluir portais gradualmente
- Criar BFF Cliente e BFF Corretor em etapas (migrando tela por tela ou feature por feature).
- Manter parceiros e webhooks fora do fluxo de frontend
- Parceiros com API dedicada e controle de escopos/quotas.
- Webhooks isolados com validação e idempotência.
6.2. Por que esta opção é boa para transição¶
- Permite lançar o superapp com contrato limpo sem “exportar” o legado para o mobile.
- Reduz risco de ruptura: portais podem continuar funcionando enquanto o novo canal evolui.
- Mantém espaço para refatorar o core internamente, sem depender do frontend.
7. Principais prós e contras¶
7.1. Prós¶
- Segurança por superfície: cada canal só acessa o BFF dele.
- Cada canal tem payload/fluxo ideal sem entortar o core.
- Evita “contrato Frankenstein” tentando servir todos.
7.2. Contras¶
- Mais serviços para operar.
- Risco de duplicar lógica se o BFF virar mini-sistema.
- Debug/troubleshooting mais chato (mais hops).
8. Quando esta opção faz sentido¶
- Quando superapp e portais têm diferenças reais de UX/payload.
- Quando você quer evoluir rápido cada canal sem quebrar os outros.
- Quando você precisa conviver com legado e quer encapsular complexidade sem “vazar” para os frontends.