Backend For Frontend - BFF

[felquis]

Inspirado neste conversa aqui #899 criei este tópico pois sinto que há pouca discussão focada no tema "BFF = Backend For Front-end" não confundir com "Best Friend Forever" quero abrir o tópico para perguntar qual é a experiência de vocês com o assunto.

Ultimamente, tenho usado muito disso:

• Tem um backend que serve de apoio ao front-end, apenas para criar o front-end, ex: remix, nextjs, ou mesmo um express com único propósito definir e servir o front-end, consumindo APIs mas não as definindo.
• E um backend que é 100% focado em definir modelos de dados e uma API que de fato diz como os dados devem ser manuseados entre a API e o banco de dados, e que geralmente implementa umas regras de negocio re-usadas em todos os client-sides que a consomem.

Dessa forma, se o front-end precisa de alguma senha secreta, o BFF é que lida com essa informação sem nunca servir a informação ao client-side, e sem misturar uma lógica de modelo de negocio da API com uma lógica de apresentação complexa apenas necessárias no front-end para web.

Um repositório de demo que tenho que mais ou menos mostra isso, mas não usa-o na prática de maneira avançada é este https://github.com/felquis/entity-to-entity-sql

• pois o schema do banco de dados e a API são publicadas em um servidor
• e o front-end é publicado em outro servidor focado nos benefícios do BFF que mencionei

---

Outro exemplo que tenho de BFF com remix que está publicado na vercel é este https://entrance-seven.vercel.app/ que apesar de usar cookies, e usar renderização do lado do servidor usando react, e usando o cookie como condicional. Ele não possui uma aplicação backend de fato, que define modelos de um banco de dados e define regras e como ler e escrever nele.

O beneficio claro que vejo é que essa separação deixa o projeto mais limpo, e com responsabilidades talvez um pouco mais fáceis de distinguir.

[luanmarques1789]

Olá, @felquis!

Algumas dúvidas que tenho a respeito desse tópico após ler o seu comentário, mas saiba que eu estou em processo de aprendizagem. Portanto, eu sou leigo sobre desenvolvimento web, principalmente quando se trata de patterns, arquitetura de projeto e renderização.

1. Se um front-end utiliza um framework back-end para rotas, ele não deixaria de ser front-end? Há alguma alternativa javascript puro para isso? Vejo que essa última forma é interessante quando se trata de evolução do conhecimento. Eu penso que utilizar muitos frameworks sem saber o seu respectivo objetivo e funcionamento é um "tiro pela culatra".

2. É possível definir rotas no front-end sem utilizar frameworks?

3. Este meu projeto expressjs poderia ser um exemplo de back-end?

[felquis]

Entendi, vou tentar responder assim:

1.1) Se usa um framework para definir as rotas do front-end, ele é sim um backend.
1.2) o expressjs é o melhor exemplo disso.
1.3) você tem razão nisso.

2. No front-end a "definição" de rota é uma questão de verificar a URL e decidir se executa ou não ou código para ela, cada lib e framework faz isso de maneiras parecidas mas um pouco diferente uma das outras, ex: para definir parâmetros de URL e partes dinâmicas na URL.

3. Se é um expressjs é um backend sim, e se você usa-lo "apenas" para definir as rotas, usar uma template engine, e servir o código necessário para o front-end e fazer algo que faz data fetching auxiliando o front-end, isso seria um exemplo de BFF.

Espero ter ajudado o/

[alysnnix]

Gostei muito do tópico levantado, também tenho muita dúvida em relação ao BFF, principalmente porque recentemente meu chefe me pediu para dar uma pesquisada sobre "rodar um servidor node por trás do front-end", e dai então descobri que essa prática se chama BFF mas venho buscando aprender mais para entender as vantagens dessa prática, algumas você mesmo ja citou.

No caso da minha empresa nós temos um back-end rodando em python, e, muitas vezes as interfaces acabam sendo lançadas antes do back, por conta disso acontece muito do back retornar umas coisas que a gente não precisa pro front, dai o que a gente faz é pegar tudo que ele retorna na requisição e converter pro formato do json mocado que criamos para construir a interface, acontece muito de usar umas 5 informações de 10 retornadas, isso seria uma vantagem de usar o servidor node antes que ele mesmo poderia fazer esse filtro para o front, ate mesmo por uma questão de segurança, como o node é javascript e usamos react no front, não seria uma dificuldade o próprio front fazer esse tratamento com node js.

Bom esses foram alguns pontos que consegui levantar ate agora mas também gostaria de ouvir mais casos de usos antes de escrever um relatório completo, vou esperar mais respostar aqui no fórum. ^^

[felquis]

Cara, este assunto de informações retornadas para o front-end que não eram necessárias, é algo que tem solução no próprio REST e no GraphQL a solução é por padrão. Talvez seja uma questão de ver quantos bytes inúteis são retornados, para ver no total de requests deferidos quanto de bandwidth é consumido por estes fields não usados. Dependendo do tamanho da aplicação, remover estes fields podem gerar uma economia importante para a empresa.

Mesmo na comunicação entre servidores, no caso de uma API para um BFF a bandwidth de campos não necessários ainda acontece, mas acredito que isso só se torna algo relevante quando a API tem centenas de milhares de requisições.