Escrito por: Jean Carlos M. da Silva

Fala, galera! 👋 Continuando o papo sobre “API” da semana passada, hoje o assunto é sobre um padrão de arquitetura que pode turbinar a experiência dos seus usuários e deixar o desenvolvimento do frontend mais suave: o famoso BFF (Backend for Frontend)! 🚀

Sabe quando você vai num restaurante 🍽️ e pede um prato? Você não quer ir na cozinha 🍳 falar com cada cozinheiro pra pedir um pouquinho de cada ingrediente, né? Você fala com o garçom 🤵, que entende +EXATAMENTE o que você quer e traz tudo bonitinho na sua mesa. O BFF é tipo esse garçom, só que pro seu app! 😉

Pra entender melhor, bora lembrar de dois caras que manjam muito do assunto: Sam Newman e Phil Calçado. O Newman, que é fera em microsserviços, simplifica a ideia do BFF como ter “um backend por experiência do usuário”.

Ele bate na tecla de que cada app (mobile, web, etc.) merece um “garçom” exclusivo no backend, feito sob medida pra ele. Já o Phil Calçado, que trabalhou lá no SoundCloud, foi quem botou o nome de “Backend For Frontend” nessa estratégia.

A visão dos dois é que ter um BFF dedicado pra cada tipo de cliente ajuda a evitar aquela confusão do mesmo backend tentando agradar a gregos e troianos ao mesmo tempo. 🛠️

Pra que serve essa “mágica”? ✨

Imagina que a gente tem um monte de “cozinheiros” (nossos microsserviços ⚙️), cada um cuidando de uma parte dos dados. Aí vem o seu app mobile 📱, o site 💻, o app da smart TV 📺… cada um com uma fome diferente de dados e precisando deles de um jeito específico.

Se cada frontend for direto na “cozinha” falar com cada “cozinheiro”, vira uma bagunça! 🤯 Muita conversa desnecessária, dados vindo que nem a gente pediu, lentidão… 🐌 Ninguém merece!

É aí que o BFF entra como um super-herói 🦸! Ele se coloca entre os frontends e os microsserviços, criando um “garçom” exclusivo para cada tipo de cliente.

As vantagens de ter seu “garçom” particular: ✅

• Experiência do usuário TOP! 💯: Cada frontend recebe só o que precisa, do jeito que precisa. O app mobile fica levinho e rápido 💨, o site carrega tudo lindão 🖼️, a TV mostra a série sem engasgar 🎬. Todo mundo feliz! 😄
• Frontends “relaxado” 😎: Os desenvolvedores não precisam se preocupar com a complexidade dos microsserviços. Eles falam só com o “garçom” BFF, que já entrega tudo mastigadinho. Menos dor de cabeça e mais produtividade! 🚀 Backends mais “tranquilos”🧘: Os microsserviços focam no que fazem de melhor, sem ter que se adaptar a mil e um formatos de dados diferentes. Fica tudo mais organizado e fácil de manter. 👌
• Segurança turbinada 🔒: O BFF pode cuidar da segurança específica de cada cliente. Por exemplo, um jeito de autenticar no mobile, outro no web… tudo mais seguro e personalizado.

E o API Gateway nessa história? 🤔 Não é a mesma coisa? 🤔

Pensa no API Gateway como a porta principal do restaurante 🚪. Ele recebe todos os clientes, vê quem tem permissão pra entrar, qual o cardápio geral, etc. Ele é o ponto de entrada único pra nossa galera acessar os serviços.

Já o BFF é o garçom específico de cada mesa 🪑. Ele conhece os gostos daquela mesa, sabe o que eles querem pedir e como eles querem que o prato venha.

Eles podem trabalhar juntos? SIIIM! 🤝

Numa arquitetura moderna, é super comum ter o API Gateway como a porta de entrada, e ele direciona cada tipo de cliente para o seu BFF exclusivo. É tipo ter um recepcionista que te leva até o garçom certo pra sua mesa! 🔝

SHOW ME DE CODE !!! 😋

Imagina um BFF para um app mobile de e-commerce. Ele precisa trazer só o nome e o preço dos produtos, sem a descrição completa pra economizar dados.

// Controller do BFF para mobile
[ApiController]
[Route("api/mobile/produtos")]
public class MobileProdutosController : ControllerBase
{
    private readonly IProdutoService _produtoService;
    public MobileProdutosController(IProdutoService produtoService)
    {
        _produtoService = produtoService;
    }
    [HttpGet]
    public async Task<IActionResult> GetProdutosMobile()
    {
        var produtos = await _produtoService.ObterProdutosParaMobile();
        var produtosViewModel = produtos.Select(p => new ProdutoMobileViewModel
        {
            Nome = p.Nome,
            Preco = p.Preco
        });
        return Ok(produtosViewModel);
    }
}

Agora, imagina um BFF para o site, que precisa de mais detalhes:

// Controller do BFF para web
[ApiController]
[Route("api/web/produtos")]
public class WebProdutosController : ControllerBase
{
    private readonly IProdutoService _produtoService;
    public WebProdutosController(IProdutoService produtoService)
    {
        _produtoService = produtoService;
    }
    [HttpGet]
    public async Task<IActionResult> GetProdutosWeb()
    {
        var produtos = await _produtoService.ObterProdutosComDescricao();
        var produtosViewModel = produtos.Select(p => new ProdutoWebViewModel
        {
            Nome = p.Nome,
            Descricao = p.Descricao,
            Preco = p.Preco,
            Qtds = p.Qtds
        });
        return Ok(produtosViewModel);
    }
}

O código ácima é apenas para fins didáticos e não deve ser usado para ambientes produtivos.

Percebe a diferença? Cada BFF fala com o mesmo microsserviço, mas entrega os dados formatados especificamente para o seu cliente! 😉

Mas nem tudo são flores… Os tradeoffs do BFF 🥀

Como tudo na vida, o padrão BFF também tem suas “desvantagens”. É importante ter uma visão realista e saber que nem sempre ele vai ser a melhor solução.

• Mais “cozinheiros” pra cuidar 🧑🍳: Implementar o padrão BFF significa ter mais um serviço rodando, o que aumenta a complexidade da nossa arquitetura. Precisamos monitorar, escalar, garantir a segurança… é mais trabalho! 😅
• Código repetido? 🤔: Pode acontecer de diferentes BFFs precisarem de lógicas parecidas, levando à duplicação de código. É preciso ficar de olho pra não virar bagunça! 👀
• Um “passinho” a mais na comunicação 🚶: A introdução do BFF pode adicionar um pequeno atraso (latência) nas requisições, já que agora o frontend fala com o BFF, que só então fala com o microsserviço. Em apps que precisam de muita velocidade, isso pode ser um ponto de atenção. 🧐
• Mais recursos, talvez? 💰: Se tivermos muitos BFFs, vamos precisar de mais recursos de infraestrutura e mais gente pra desenvolver e manter tudo. É bom botar isso na ponta do lápis. ✍️
• Cuidado pra não exagerar! 😬: Em apps mais simples, com poucos clientes, talvez o BFF seja “tiro de canhão pra matar formiga”. É importante analisar se a complexidade extra realmente compensa os benefícios. 🤔

Por isso, antes de sair implementando BFF em tudo quanto é lugar, é fundamental analisar o cenário, as necessidades de cada cliente e os recursos disponíveis. O BFF é um padrão poderoso, mas como qualquer padrão, precisa ser usada com sabedoria! 😉

Quer saber mais? Se liga nessas dicas de leitura 😋📚

Artigo da AWS sobre BFF

Artigo do Phil Caçado sobre BFF

Artigo do Sam Newman sobre BFF

Artigo da Microsoft sobre BFF

Pra fechar o “pedido” 📝

O padrão BFF é uma carta na manga ♠️ para quem busca entregar a melhor experiência para o usuário em um mundo de microsserviços e diferentes tipos de clientes. Dá um certo trabalho extra no começo, mas os benefícios a longo prazo valem MUITO a pena! 👍

E aí, curtiram o papo? Deixem seus comentários e experiências com BFF !!

arquiteturadesoftware #microsservicos #bff #backendforfrontend #csharp #dotnet #desenvolvimento #softwareengineering

Apoio 5by5 | Soluções em Sistemas