O documento discute como o Backend for Frontend (BFF) pode ser usado para conectar serviços back-end às necessidades específicas dos front-ends. O BFF agrega e adapta dados de vários serviços e desacopla a comunicação entre front-end e back-end, trazendo vantagens como autonomia dos front-ends, domínios coesos e melhor performance. No entanto, o BFF também introduz desafios como a necessidade de manutenção de mais um componente e a possibilidade de ponto único de falha.

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