O documento discute como o Backend for Frontend (BFF) pode ajudar a lidar com diferentes frontends de forma independente. O BFF age como um intermediário entre os serviços back-end e os frontends, agregando e adaptando dados para atender às necessidades específicas de cada frontend. Embora traga mais complexidade, o BFF permite maior autonomia dos frontends, domínios back-end mais coesos e melhor performance nas comunicações de rede.

1. Como BFF (Backend for
Frontend) pode ser seu
melhor amigo para lidar
com diferentes frontends

2. Cristiano
Arquiteto Software
@crisaltmann
2

3. Deivid
Desenvolvedor Web
@deividhf
3

4. Micro serviços
Vamos falar um pouco sobre essa
buzzword...
1.

5. Micro serviços
5

6. 6
Deploy independente
Baixo acoplamento
Escalabilidade
Horizontal
Escolha tecnologias
Tempo de negócio
Times independentes
Evolução
tecnológica
Resiliente

7. SERVIÇOS
Unidades interoperáveis que podem
facilmente ser reutilizados e
compartilhados entre aplicações e
empresas
7

8. Definindo serviços
com DDD
▪ Orientado ao domínio
▪ Contextos delimitados
8
Conta
Corrente
Pessoa

9. 9

10. Dificuldades
Algumas dificuldades na adoção desta
arquitetura...
2.

11. Design
▪ Dificuldade de manter a
coesão do domínio do
serviço
▪ Necessidades UI
11

12. Rede
▪ Comunicação sujeita a
falhas
▪ Chatty
12

13. Dados
▪ Contratos dos serviços
não levam em
consideração o Front
End
13

14. Multi UI
▪ Infinidade de Front ends
consumindo os serviços
14

15. E o BFF….
3.

16. BFF
Um componente responsável por
conectar as necessidades específicas de
Front end com os serviços.
16

17. 17

18. Características
Agregação
Agregar dados de
diferentes servicos.
Adaptação
Adaptar o contrato do
serviço à necessidade do
front end.
Sem regras de negócios
As regras de negócio
devem estar nos serviços.
18

19. Quantos
BFFs?
▪ Adequar à distribuição
dos times
▪ BFFs por experiência
19

20. Vantagens
Algumas vantagens do uso do BFF
4.

21. Autonomia
do front end
▪ Mock dos dados no BFF
▪ Não depender do back
end para testar
integração
21

22. Domínios
▪ Coesos
▪ Não precisam se adaptar
às necessidades de front
ends
22

23. Chamadas
▪ Latência
▪ Rede
23

24. Teste A/B
24

25. Controle
versão
▪ Migração versões de
serviços
25

26. Diferentes
protocolos
▪ Permite que a
comunicação com a UI
seja desacoplada do
backend
26

27. Desvantagens
Alguns problemas que a adoção do
pattern nos traz
5.

28. Mais um
componente...
28

29. Ponto único de
falha
29

30. Conclusão
Aprendizados sobre o uso do pattern
6.

31. Mantivemos
sistemas
coesos
▪ Graças ao BFF
31

32. Tecnologias
▪ Devem ser simples
▪ Sem verbosidade
32

33. Habilidades
▪ Complexidades do back
end levados ao front
33

34. Obrigado!
34