Em aplicações modernas, uma mesma plataforma costuma ser acessada por múltiplos tipos de clientes: web, mobile, smart TVs, apps nativos, dispositivos IoT e por aí vai. O problema é que cada um desses ambientes consome dados de forma diferente. Quando todos dependem de uma API genérica, o resultado costuma ser respostas grandes demais, desperdício de banda e muito código no frontend só para filtrar o que realmente importa.
É exatamente nesse ponto que entra o padrão de projeto Backend-for-Frontend, ou simplesmente BFF.
O problema das APIs genéricas
Imagine um endpoint como /user. Ele normalmente retorna tudo sobre um usuário: nome, e-mail, preferências, histórico, permissões, configurações e vários outros campos. Isso faz sentido do ponto de vista do backend, porque atende a todos os consumidores possíveis. Mas, para o frontend, quase sempre é exagero.
Um app mobile pode precisar só do nome e da foto. Um site desktop pode precisar do nome, e-mail e status. Um app de TV pode usar ainda menos. Mesmo assim, todos recebem o mesmo pacote gigante de dados, processam, filtram e descartam o que não precisam. Isso consome mais rede, mais CPU e aumenta a latência percebida pelo usuário.
O cenário piora quando uma única tela depende de vários serviços. Uma home de e-commerce, por exemplo, costuma chamar user, catalog, cart, pricing e promotions. O frontend precisa fazer várias requisições, esperar todas responderem, tratar erros e depois juntar tudo para renderizar a página. A lógica fica espalhada no cliente e o backend vira um gargalo, tentando agradar todos os tipos de interface ao mesmo tempo.
O que o BFF resolve
O BFF muda a lógica do jogo. Em vez de uma API genérica para todo mundo, você cria uma API dedicada para cada tipo de frontend. Em outras palavras, um backend feito sob medida para aquele frontend específico.
A API do mobile só retorna o que o mobile precisa. A do desktop só entrega o que o desktop consome. A da TV ignora tudo que não faz sentido para aquele dispositivo. Isso reduz payload, simplifica o código do cliente e deixa a experiência mais rápida e previsível.
Além disso, o BFF pode agregar dados de vários serviços em uma única chamada. Em vez de o frontend falar com cinco APIs diferentes, ele chama apenas o BFF, que faz as requisições necessárias, junta os dados e devolve uma resposta já no formato ideal para aquela tela.
Como o KrakenD entra nessa história
O KrakenD implementa o padrão BFF de forma nativa. Ele permite que você crie endpoints que agregam dados de múltiplos backends e ainda filtre exatamente quais campos devem ir para o cliente.
Você define, por exemplo, que o endpoint /frontpage deve buscar dados no serviço de usuários e no serviço de catálogo, mas só retornar alguns campos específicos. O gateway cuida de chamar os serviços, tratar respostas, agrupar tudo e entregar um JSON pronto para o frontend consumir.
Na prática, o cliente recebe:
- Apenas os dados que realmente precisa
- Tudo em uma única requisição
- Informações vindas de vários serviços já agregadas
- Respostas mais leves, rápidas e fáceis de usar
Isso desacopla o frontend do backend de propósito geral. Se um serviço interno muda, o BFF pode se adaptar sem quebrar o app. Para quem desenvolve interface, isso é ouro.
BFF e experiência do usuário
Dispositivos diferentes têm capacidades diferentes. Um desktop lida melhor com respostas grandes. Um celular, nem tanto. Quando todo mundo usa a mesma API genérica, o usuário mobile tende a sofrer mais com lentidão e consumo de dados.
Com BFF, cada interface ganha uma API afinada para sua realidade. O tempo de resposta entre desktop e mobile fica mais parecido, porque cada um recebe apenas o que consegue processar bem. Além disso, APIs dedicadas podem expor funcionalidades específicas de cada dispositivo, como leitura de QR Code, sensores ou notificações nativas.
Autonomia para os times
Outro ponto forte do BFF é organizacional. Em muitas empresas, a equipe que faz o frontend não é a mesma que cuida dos serviços de backend. As duas evoluem em ritmos diferentes e isso gera atrito.
Quando o BFF pertence à equipe do frontend, ela passa a ter controle sobre sua própria API. O time pode ajustar formatos, mover lógica para o servidor, criar endpoints específicos e iterar rápido, sem depender de longas negociações com outras equipes. Os serviços centrais continuam existindo, mas o BFF vira uma camada de adaptação focada na experiência do usuário.
Quando faz sentido usar BFF
Se você tem apenas um site simples, talvez uma API genérica resolva. Mas, a partir do momento em que entram mobile, apps nativos, parceiros ou dispositivos diferentes, o BFF vira uma solução quase natural.
Ele é especialmente útil quando:
- Uma tela depende de vários serviços ao mesmo tempo
- Você quer reduzir payload e chamadas de rede
- Cada tipo de cliente precisa de dados em formatos diferentes
- Times de frontend e backend trabalham de forma independente
Empresas grandes como SoundCloud e Reddit já usam esse padrão há anos porque ele escala melhor, tanto tecnicamente quanto em termos de organização.
No fim das contas, o BFF não é só uma arquitetura. É uma forma de aceitar que cada interface é única e merece uma API que fale exatamente a sua língua.
