Quem é o BFF na fila do pão?

Explicando back-end for front-end para quem não é da área de tecnologia.

bia zago
UX Collective 🇧🇷

--

Ilustração de uma padaria, com um balcão, vitrine de pães e quitandas, duas mesas com cadeiras, quadros e plantas.

Claro que vou começar com uma piada de tia (até mesmo porque eu estou no meu local de fala, sou realmente uma tia):

Não, o texto não é uma homenagem para a minha melhor amiga.

BFF é um sigla para back-end for front-endtermo criado em 2015 por Phil Calçado, e é um padrão para API que permite equipes a iterarem recursos mais rapidamente e terem controle sobre o backend, sem afetar o frontend e também gerar experiências específicas de acordo com cada pessoa usuária de um determinado produto.

Tentarei, com o meu olhar de product designer, em uma analogia, traduzir o que isso significa e quais são as suas principais vantagens.

Já que estamos falando da fila do pão, nada melhor do que uma padaria para ilustrar isso.

O back-end

Ilustração de uma padaria, com foco na área atrás do balcão, onde tem vários pães e quitutes. Na área existe um texto onde lê-se backend.

Dentro da padaria, no backend está tudo o que os clientes querem e precisam consumir. Porém, dependem de alguém para preparar e entregar para eles.

Sendo assim, o desenvolvedor backend seria o padeiro, e os serviços seriam os pães, cafés, sucos, quitutes, etc.

Tudo isso está em uma área da padaria onde os clientes não têm acesso.

O front-end

Ilustração de uma padaria, com foco na área das mesas e cadeiras. Existe um texto onde lê-se frontend.

Já o frontend é a área onde esses clientes têm acesso.

Nessa área eles conseguem escolher onde sentar, podem consultar o cardápio de produtos e decidir o que querem beber e comer.

O desenvolvedor frontend na padaria é o garçom: ele anota os pedidos, repassa para o padeiro e depois entrega o pedido certo para cada cliente.

Até aí tudo muito fácil de entender, certo?

O dia a dia na padaria

No backend há uma gama grande de produtos:

O padeiro poderia montar kits padrões de café da manhã, com pão na chapa, café preto, salada de frutas e uma fatia de bolo, por exemplo, e entregar os kits diretamente para o garçom.

Uma padaria assim até funcionaria, claro. Ela resolveria o problema de muitas pessoas todas as manhãs. Mas algumas pessoas não gostam de bolo, e outras preferem o café com leite, fora que a longo prazo as pessoas que gostam do kit poderia cansar de comer as mesmas coisas todos os dias, e é bem provável que deixariam de frequentar essa padaria.

E onde entra o BFF nessa história?

O BFF na padaria

Para gerar mais valor para esses clientes, e consequentemente rentabilizar mais a padaria, entra o tal do BFF: O BFF nessa padaria é o balcão!

Ilustração de uma padaria, com foco no balcão, onde tem uma bandeja com alguns pães e outros. Na área existe um texto onde lê-se BFF.

É nesse balcão que o garçom entrega o pedido de cada cliente anotado:

O padeiro recebe o pedido, monta a bandeja personalizada de cada um, e disponibiliza novamente no balcão, para que o garçom retire e entregue para quem fez o pedido.

O BFF funciona como um filtro de todos os produtos existentes atrás do balcão e permite a personalização de cada pedido.

As vantagens do BFF

Voltando então para os nossos tão amados produtos digitais, com o BFF pensamos em UX (user experience) e DX (developer experience), e por isso as vantagens são muitas:

Imagine uma tela de cadastro, onde é preciso apenas o email do usuário. O frontend consome uma API inteira que possui todos os campos (nome, CPF, RG, nome da mãe, telefone, CEP, demais campos de endereço, etc) para depois exibir somente o input do email na tela. O JSON disso é grande. Através do backend, o BFF faz um filtro e entrega para o front somente o necessário, deixando tudo bem mais leve.

Outra vantagem: pense agora na Home de um aplicativo, onde temos diversos endpoints para consultar, como perfil do usuário, notificações, uma métrica principal, atalhos diversos, publicidade, parceiros. Só aqui nesse exemplo seriam pelo menos 6 endpoints. Seriam então 6 requisições feitas pelo frontend para gerar essa tela. Não seria tão rápido, né? Com o BFF, o backend poderia otimizar esse processo e disponibilizar através dele tudo que deve ser exibido na tela em um único endpoint, e assim o front faria apenas 1 requisição. Ou ainda poderia dividir os endpoints em grupos para chamadas que façam sentido para essa Home. A vantagem de dividir em grupos, é que caso o BFF falhe, não fique a Home inteira fora do ar, mas apenas o grupo da falha.

Só até aqui já falamos de algumas vantagens que resultam numa melhor performance do produto.

Imagem de dois wireframes mobile com pequenas diferenças entre si, e um texto sobre cada um indicando teste 1 e teste 2.

Pensando em experiência do usuário, O BFF permite também um conteúdo dinâmico e personalizado na interface. E a melhor parte, é que conseguimos usar o backend para fornecer isso, sem depender de atualizações na App Store e Play Store, podendo assim atualizarmos esse conteúdo constantemente.

Para conseguirmos essas vantagens, podemos utilizar o Beagle, ferramenta open source da Zup (links úteis ao final do texto).

O Beagle é um facilitador do BFF e está disponível para Android, iOS e Web e nos permite alterar a interface e até fluxos através do backend, porque sua arquitetura está estruturada em Server Driven UI.

Muito bom, não é mesmo? Em uma única versão na loja, conseguimos ter um aplicativo diferente a cada dia, da maneira que quisermos, e com isso podemos validar hipóteses e mitigar riscos com base em dados. Sabemos que eles não mentem.

Feature flag

Ilustração de dois botões toggle, um ligado com o texto feature flag on, e o outro desligado com o texto feature flag off.

E já que estamos falando em explorar o poder do backend na criação de interfaces e testes em produção, trago esse tópico que não necessariamente precisa ser no BFF, mas que é vinculado ao back: criar as funcionalidades do produto com feature flag, o famoso toggle.

Essa possibilidade de ligar ou desligar alguma funcionalidade, fluxo ou até mesmo algum produto dentro de uma plataforma, ajuda também, assim como o Beagle, a realizar alguns testes em produção. Mas não só isso. Com o toggle, você pode desligar uma funcionalidade que está em manutenção, ou com algum problema que causa instabilidade, por exemplo. Em muitos casos é melhor a pessoa usuária nem ver determinada funcionalidade do que cair em uma tela de erro e se frustrar, concorda?

A ideia é ser sempre ágil

Mitigar riscos de valor e usabilidade vai além de pesquisas e testes com protótipos, e experimentos em produção podem ir além de testes A/B.

E para testar rápido, validar rápido, errar rápido e aprender rápido, e com isso gerar valor e entregar a melhor (e personalizada) experiência para o seu usuário de forma rápida, use o combo da alegria para qualquer profissional de produto: BFF + Beagle + Feature flag.

O Charles, outro produto open source da Zup, potencializa tudo isso com deploys em círculos, mas deixo esse assunto para outro momento. Ando explorando essas opções no produto onde atuo, já tive vários aprendizados interessantes, e recomendo.

Pensou em customização, pensou em BFF.

E fala a verdade, você nunca imaginou que um balcão poderia fazer tanta diferença na sua vida, no seu produto e na vida de seu cliente, não é mesmo?

Referências

Me encontre no LinkedIn e Instagram.

Revisão técnica por Thiago Tavares

O UX Collective doa US$1 para cada artigo publicado na nossa plataforma. Esse artigo contribuiu para a World-Class Designer School: uma escola de design gratuita de nível universitário, com foco em preparar designers africanos jovens e talentosos para o mercado de produtos digitais local e internacional. Construa a comunidade de design na qual você acredita.

--

--

Apaixonada por pessoas, detalhes, inovação e diferentes manifestações criativas. Designer há + de 15 anos, atualmente dedicada à Produtos Digitais e sua gestão.