BFF: Padrão de APIs pensando para frontend

Antes na maioria das aplicações, o frontend e backend eram juntos, ou seja, eram monolitos e estavam na mesma aplicação. Com passar do tempo a arquitetura foi evoluindo, por exemplo, o backend começou a ter outras necessidades e a ficar mais complexo. 

Do mesmo modo, outras demandas surgiram no frontend, tornando-o mais especializado. A partir daí, Tyemy Kuga, Tech lead na Dextra, comenta que surgiu a necessidade de uma divisão de times, um backend e outro frontend. 

Com a evolução dos monilitos chegasse ao modelo de microsserviço, que resulta em melhorias no backend e um frontend conectado a vários microsserviços diferentes. Essa transição ocorreu como um resultado ao grande aumento do número de usuários, questões envolvendo escalabilidade e manutenção de código. 

Quais as dificuldades comuns? 

No modelo de microsserviços com apenas um frontend era preciso fazer várias chamadas em diferentes serviços, o que levava a UI exibindo informações de domínios diferentes e serviços retornando dados que não seriam usados pela tela. Com o padrão BFF (Backend for  Frontend) temos serviços mais especializados, obtenção das informações que compõe a tela em menos chamadas e simplicidade das chamadas no frontend. 

Como Tyemy Kuga explica, o foco do BFF é na lógica de apresentação, ou seja, a ideia não é adicionar uma lógica de negócio, ter muitas camadas de acessos a dados ou muitas regras. Outra dúvida que a Tech lead comenta, é sobre a necessidade de ter sempre um BFF. 

Para ela isso depende de alguns fatores: se sua aplicação é monolito ou microsserviço, se você tem vários frontends que mostram informações diferentes (por exemplo, um aplicativo no celular e uma página web com conteúdos diferentes), se você acessa muito microsserviços ou se você faz uma integração com serviços de terceiros.

Quer entender mais sobre o tema? Veja o vídeo completo!

Este artigo foi escrito por Tyemy Kuga e publicado originalmente em Prensa.li.