A evolução dos backends

for frontends no iFood

Como adaptamos nossa abordagem em direção ao padrão de arquitetura para melhorar nosso dia-a-dia
Acesse menti.com e use o código 82 54 3
O iFood
Números e pilares
Números do iFood em Março em 2019
Números do iFood em Novembro em 2019
Números do iFood em Março/2020
● 30,6M pedidos

● 1K cidades

● 160K parceiros

● 170K entregadores
Consumer Restaurants Logistics

Os três principais pilares do iFood

O padrão de projeto
Backend for Frontends (BFF)
Serviços backend especializados em frontends ou clientes externos
Uma API backend de propósito geral [1]
Exemplo de clientes com necessidades diferentes
Uso de um BFF por cliente [1]
Backends específicos para desacoplar necessidades específicas de cada cliente
Backends específicos para desacoplar necessidades específicas de cada cliente
Primeira abordagem do BFF
Como inicialmente o padrão foi aplicado no serviço do portal do parceiro
Abordagem de um BFF por cliente no iFood
Arquitetura simplificada do portal do parceiro
Times que compartilhavam a base de código do BFF do portal do parceiro
Problemas da primeira versão do BFF
● Tempo de promoção de novas versões
○ Em média 24 minutos

● Tempo de deploy
○ Em média 10 minutos

● Tempo de startup da aplicação

○ Em média 57 segundos

● Escalonamento ineficaz
○ Diferentes necessidades compartilhadas pelo mesmo processo
Evoluindo nosso BFF
Como resolvemos os problemas citados anteriormente
Contraste entre a abordagem inicial à esquerda e abordagem proposta à direita
Desafios da evolução BFF
● Interesses transversais
○ Permissionamento
○ Auditoria
○ Configurações
○ Validação do Token JWT

● Criação de múltiplas aplicações

○ Definição de estratégias de migração
○ Documentação para criações de aplicações dessa natureza

● Controle de impactos
○ Várias features sendo migradas ao mesmo tempo
Lidando com interesses
transversais
Criando uma biblioteca base para nossos BFFs
Interesses transversais do BFF do portal do parceiro
Criação de biblioteca base para interesses transversais dos BFFs
Criação de múltiplas aplicações
Como nós impulsionamos a criação dos novos BFFs
Estratégias de migração
● Novas aplicações
○ Strangler application [2]
○ Aplicações criadas "do zero"
○ Stacks variando por time

● Fork do projeto antigo

○ Integração com biblioteca base
○ Remoção de código não utilizado no contexto
Documentação
● Criação de infraestrutura com exemplos
● Padrões de monitoramento
● Padrões de nomenclatura
● Integração com a biblioteca base
● Relação entre APIs existentes e novos BFFs
Controlando impactos e
realizando a migração
Como mitigar os impactos de migrar várias features ao mesmo tempo
Balanceamento de carga via Kong
routes:
- name: route-bff-service
service: bff-service
paths: ["/restaurant/reviews"]
services:
- name: bff-service
protocol: http
host: upstream-bff
path: "/"
upstreams:
- name: upstream-bff
targets:
- target: host-service-1:80
weight: 90
- target: host-service-2:80
weight: 10

Versão simplificada da definição de novas rotas do Kong

Resultados da migração
Contrastando o cenário anterior com o cenário atual
Comparação entre o tempo médio de promoção de artefatos da versão anterior e das novas versões
Comparação do tempo de promoção de novos artefatos da versão anterior (linha tracejada) e todas as novas versões
Comparação entre o tempo médio de deploy da versão anterior e das novas versões
Comparação do tempo de deploy da versão anterior (linha tracejada) e todas as novas versões
Comparação entre o tempo médio startup da versão anterior e das novas versões
Comparação do tempo de startup da versão anterior (linha tracejada) e todas as novas versões
Tradeoffs
Pontos negativos da evolução dos BFFs
Tradeoffs da evolução dos BFFs
● Rodar os BFFs localmente junto com o frontend
● Localizar BFFs que expõem as APIs que o cliente consome
● Definição de contexto de novas features
● Definição do limite das responsabilidades
● Maior uso de recursos
Obrigado pelo convite, ARQTI! Acesse menti.com e use o código 82 54 3

Faça parte dessa revolução! Fale comigo:

https://boards.greenhouse.io/ifood roberto.elero@ifood.com.br
Referências
● [1] Pattern: Backends For Frontends by Sam Newman
● [2] Pattern: Strangler Application