Dev
Architecture
BFF
1.bff

Back-End for Front-End (BFF)

Backend for Frontend é uma arquitetura que visa desacoplar o frontend de várias request para microserviços para fazer uma request única para o BFF. O BFF, por sua, vez irá fazer as requests para os microserviços e agrupar e transformar os dados para o frontend consumir.

Microservices

Microserviços usam API Gateway para juntar requisições de vários serviços para fornecer uma API limpa para o frontend, além disso cuida de rate limit e autenticação, por exemplo.

Alguns benefícios da API Gateway:

  • Desacoplamento
  • Modularidade

Microservices Agregation: API Gateway == API Composition

Problema

Se as diferentes UIs quiserem fazer o mesmo ou muito semelhante tipo de chamada, pode ser fácil que esse tipo de API de uso geral seja bem-sucedido. No entanto, a natureza de uma experiência móvel geralmente difere drasticamente de uma experiência na Web de desktop.

Outro problema com o back-end da API de uso geral é que eles estão, por definição, fornecendo funcionalidade para vários aplicativos voltados para o usuário. Isso significa que o back-end de API único pode se tornar um gargalo ao lançar uma nova entrega, pois muitas alterações estão tentando ser feitas no mesmo artefato implantável.

A tendência do back-end da API de uso geral assumir várias responsabilidades e, portanto, exigir muito trabalho

Backend for Frontend

É uma API gateway só que para cada aplicação Frontend, visando obter o menor número de recursos possíveis.

BFFs devem fornecer dados da maneira mais conveniente possível para as necessidades de seus clientes.

O BFF é fortemente associado a uma experiência específica do usuário e normalmente será mantido pela mesma equipe que a interface do usuário, facilitando a definição e adaptação da API conforme a interface do usuário, além de simplificar o processo de alinhamento da liberação dos componentes do cliente e do servidor. O BFF está fortemente focado em uma única interface do usuário e apenas nessa interface do usuário. Isso permite que ele seja focado e, portanto, será menor.

Cada Front-end tem que ter seu próprio BFF. Exemplo: BFF ↔ Android | BFF ↔ IOS.

Uma única chamada para um BFF pode resultar em várias chamadas a jusante para microsserviços. Do ponto de vista da eficiência, seria muito mais inteligente executar o maior número possível de chamadas em paralelo.

bff.png

BFF pode ser construído com REST ou GraphQL. Deve ser usado cache para melhorar a performance e evitar chamadas desnecessárias para os microserviços. Usar invalidação se necessário.

team-ownership.jpg

O cenário ideal para utilizar BFF é quando há necessidade significativa de agregação do lado do servidor, ou quando precisa fornecer funcionalidades distintas para cada aplicação.

Perimeter layer

Perimeter layer (api management layer) pode ser usada para Authentication, Throttling e Routing

Fqbjf1gXsAEiVeu.jpeg

Problemas do BFF

  • Duplicação de código: solução é criar bibliotecas para compartilhar a mesma lógica.
  • BFF com muitas responsabilidades: manter desacoplamento.
  • Aumento de esforço pois é mais uma aplicação para desenvolver e dar manutenção.

Referências