← ← ← 5/2/2022, 6:59:05 PM | Posted by: Felippe Regazio
Imagine o cenário: vc tem um produto que é dividido em uma SPA (front) e uma API (back). Seu produto começa a crescer e começa a ter times
Vc tem o core team que cuida da SPA e da API Vc tem agora um time de SRE que cuida da infra E um time de Mobile que ta fazendo um app mobo
Tudo vem dando muito certo e vc cresce ainda mais:
Vc agora tem um time de Design Vc tem um time de front que vai fazer um DS Um time de security que ta fazendo um single sign on Vc tem um time dedicado ao front da SPA Um time de back dedicado a API O SRE O time Mobile
Etc
Massa, seu produto ta indo bem, mas um dia o tech lead do time de backend que cuida da Core API te trás os seguintes problemas
O time da API ta fazendo muita coisa, todos os outros times endereçam issues ou necessidades pra lá, por ex:
O segundo problema relatado pelo lead é: Os times são muito especificos - times só de backend e times só de front end - de forma que parte do horizonte de integração se perdeu e o front gera retrabalho pro back e vice-versa, e as solicitações não são tão acertivas
O terceiro problema: O diferentes clients expõem a Core API pra todo canto da internet. Tem um monte de tráfego vindo de diferentes direções atraindo bots, ataques, expondo muito a API e tornando os logs uma bagunça só.
Vc pensa em contratar mais backenders pra resolver o problema 1. mas isso nao resolve o problema 2 e 3. Vc pensa em escalar infra pra resolver o problema 3. mas isso não resolve o 2, vc pensa em envolver o time de security. Na real vc não sabe o que fazer.
Então vc percebe que foi um erro ter isolado os times de front (pure front). vc contrata novos backs e coloca nos times de front. Esses backs podem fazer PR para a Core API desafogando o time de lá e dando autonomia aos times de front. Vc escala um pouco a infra e pronto!
Massa, vc resolveu o problema 1, 2 e 3. Tudo vai bem por algumas semanas até que o tech lead do time de backend que cuida da Core API retorna pra vc com outras reclamações:
As equipes client estao subindo muita coisa, muito code review pra fazer, muita demanda especifica, muito crap code, o git da Core API ta confuso
O time Core API acha ruim não ter autonomia total do projeto, e está achando o changelog inconsistente pq terceiros o modificam
O techlead diz ainda que ter escalado a infra não adiantou muito, os custos subiram mas a API continua exposta e vcs continuam recebendo ataques. Vc não sabe mais o que fazer... Vc contrata serviços terceiros de segurança, vc escala na AWS, vc ta queimando dinheiro noo 🔥🔥🔥
Calma, isso é um trabalho para o BFF. Um engenheiro surge do nada e diz:
Precisamos implementar um "Back For Front". Cada equipe de front end vai ter um backend proprio pra onde o client delas aponta. A de SPA vai ter um spa-back, a de Mobile um spa-mobile, etc
Esses backends vão receber as requisições dos clientes e negociar com a Core API. Os BFFs (back for front) não terão acesso direto ao DB, mas sim a uma coleção de rotas genericas da Core API. O time de Core cuida e evolui apenas as rotas genericas e contratos com DB.
Os times BFF evoluem demandas especificas e não cuidam de nada que envolva DB. Ex: Vc quer croppar imagens on the fly pro seu front? Legal, vc implementar isso no seu BFF (seu proprio backend), o seu BFF trata a imagem e chama a rota da Core API simplesmente pra salvar a imagem
O time Mobile precisa das imagens que vem na API sempre tratadas pra width menor ou igual a 760px? Ok, eles criam isso no BFF deles, pedem a imagem pra Core API, tratam como quiserem e devolvem pro client.
Quanto aos problemas de segurança: A Core API será fechada para o mundo e estará disponível via gateways especificios que só os BFFs podem enxergar. Assim, os trafegos externos não sabem que a Core API existem, na pior das situações conseguirão derrubar um BFF, dane-se.
Cada equipe agora é uma equipe full stack (tem tanto dev front e back e cuida do processo de ponta a ponta) com exceção da Equipe Core API que cuida apenas do core mais pesado e generico de backend/db.
Pronto: Todos os problemas que o tech lead trouxe foram resolvidos. Foi adicionada uma pequena camada de complexidade e escala ja que tem um novo backend pra cada time, mas se for ver, essa complexidade ja estava granulada e misturada entre os times, ela foi reorganizada.
É isso que é o BFF pattern pessoal, e esse é um dos cenários possíveis em que vale o trade off de implementar um. O BFF é um front simples que age como I/O entre o seu front end e sua api principal
Client - BFF - API
Isso da autonomia aos times, protege sua API, delimita serviços e responsabilidades, desafoga times e torna a arquitetura mais resiliente e distribuida (tem seus trade offs, é claro).
Se minha explicação foi pobre, abaixo tem um link mto bom explicando BFF Patterns em detalhes.
Sam Newman: BFF Architectural Pattern
Obs: Não estou dizendo que BFF é uma bala de prata, que é a unica solução pros problemas acima, que vc deve ou não usar. Só apresentei um cenário e mostrei como um BFF se encaixa a ele. Como e se vc vai usar its up to you.
Minha opinião super pessoal: Tenho trabalhado com BFFs e curtido bastante, realmente trás beneficios. Mas tem tradeoffs, tem sidecases tbm é claro (como tudo). Eu acho que não faz sentido BFF pra pequena e media aplicação, mas pode ser massa pra multi-squad giant applications 🙃