API Gateway e BFF: organizando a borda dos seus serviços
Quando um sistema cresce e se divide em vários serviços, uma pergunta prática aparece: por onde o mundo externo entra? Deixar cada aplicação cliente (o site, o app mobile, integrações de parceiros) falar diretamente com dezenas de serviços internos é uma receita para o caos. Cada cliente precisaria conhecer o endereço de cada serviço, implementar autenticação repetidamente, lidar com mudanças internas e montar suas telas juntando chamadas a muitos lugares. A borda de serviços existe para resolver isso, e ela tem algumas formas, frequentemente confundidas entre si.
Este guia esclarece as peças da borda: o proxy reverso, o API Gateway e o Backend for Frontend (BFF). O que cada um faz, quando usar cada um, e o cuidado central: impedir que a borda, feita para simplificar, vire ela mesma um gargalo ou um novo monólito disfarçado.
O ponto de entrada único
A ideia comum a toda borda é oferecer um ponto de entrada controlado entre os clientes e os serviços internos. Em vez de expor a bagunça interna, você coloca uma camada na frente que recebe todo o tráfego externo e o encaminha para os serviços certos. Isso desacopla os clientes da topologia interna: os serviços podem ser divididos, movidos ou renomeados sem que nenhum cliente perceba, porque todos falam com a borda, não com os serviços diretamente.
A partir dessa ideia comum, cada peça da borda assume um papel diferente.
Proxy reverso: o encaminhador
O proxy reverso é a forma mais básica. Ele recebe requisições e as encaminha para servidores internos, sem entender muito do que trafega. Faz balanceamento de carga entre instâncias, termina o TLS, serve conteúdo em cache e aplica regras simples de roteamento por caminho ou domínio. É uma peça de infraestrutura genérica, focada em transporte, não em regras de negócio ou de API.
API Gateway: a borda inteligente
O API Gateway é um proxy reverso turbinado, que entende que está lidando com APIs e assume responsabilidades transversais que, de outra forma, seriam repetidas em cada serviço. Ele centraliza preocupações comuns em um único lugar:
- Autenticação e autorização na borda. O gateway valida o token de acesso uma vez, na entrada, e repassa para os serviços internos uma identidade já verificada. Cada serviço não precisa reimplementar login.
- Rate limiting e cotas. Controlar quantas requisições cada cliente pode fazer é natural no ponto onde todo o tráfego passa.
- Roteamento por serviço. O gateway sabe qual serviço atende cada rota e encaminha de acordo.
- Preocupações transversais. Logging, métricas, tracing, compressão, transformação de requisição e resposta, tudo concentrado na borda.
Concentrar isso no gateway evita que cada serviço reinvente autenticação e rate limiting, e dá um lugar único para aplicar políticas de segurança. Esse é o maior valor do padrão: tirar do caminho de cada serviço as responsabilidades que são de todos.
Backend for Frontend: uma borda por cliente
Aqui está a peça que mais gera confusão. Um Backend for Frontend (BFF) é uma camada de borda dedicada a um tipo de cliente específico. Em vez de um gateway genérico servindo a todos, você cria um backend sob medida para o app mobile, outro para o site, outro para integrações de parceiros.
O motivo é que clientes diferentes têm necessidades diferentes. O app mobile, com tela pequena e rede instável, quer respostas enxutas e agregadas: uma única chamada que já traz tudo o que a tela precisa. O site, com mais espaço e banda, pode querer dados mais ricos. Um BFF agrega as chamadas a vários serviços internos e molda a resposta exatamente para o formato que aquele cliente consome, poupando o cliente de fazer muitas chamadas e de montar dados na mão.
Agregação: o ganho central do BFF
A agregação é o que o BFF faz de mais valioso. A tela de um pedido pode precisar de dados de três serviços: pedido, cliente e entrega. Sem BFF, o app faria três chamadas e juntaria tudo. Com BFF, o app faz uma chamada, e o BFF, mais perto dos serviços e com rede rápida entre eles, busca as três partes e devolve prontas. Menos idas e voltas pela rede lenta do cliente, mais eficiência na rede interna.
Comparando as peças
| Peça | Papel principal | Foco | Quando usar |
|---|---|---|---|
| Proxy reverso | Encaminhar e balancear | Transporte | Roteamento e TLS simples |
| API Gateway | Borda transversal para APIs | Autenticação, rate limit, roteamento | Muitos serviços, um ponto de entrada comum |
| BFF | Borda sob medida por cliente | Agregação e formato de resposta | Clientes com necessidades bem diferentes |
Elas não são exclusivas. Uma arquitetura madura frequentemente tem um gateway na frente cuidando de autenticação e rate limiting, e BFFs por trás dele agregando dados para cada cliente. Cada peça resolve um problema distinto na mesma borda.
Quando a borda vira o problema
A borda existe para simplificar, mas mal desenhada ela cria dois riscos sérios que anulam o benefício.
O primeiro é o gargalo. Como todo o tráfego passa pela borda, ela é um ponto crítico: se o gateway fica lento ou cai, tudo fica lento ou cai junto. A borda precisa ser altamente disponível, escalável horizontalmente e leve. Colocar lógica pesada demais nela é pedir para transformá-la no gargalo de todo o sistema.
O segundo, mais insidioso, é a borda virar um monólito distribuído. Quando o gateway ou o BFF começa a acumular regras de negócio, ele deixa de ser uma camada de borda e vira um serviço central por onde toda mudança precisa passar. Aí você tem o pior dos dois mundos: a complexidade de operar muitos serviços somada ao acoplamento de um monólito, tudo concentrado na borda. A regra de ouro é manter a borda fina: ela cuida de preocupações transversais e de formato, enquanto a lógica de negócio fica nos serviços, onde é dona do seu domínio.
A borda como facilitadora, não como dona
Organizar a borda dos serviços é o que permite a um sistema distribuído apresentar uma face simples e coerente ao mundo, escondendo a complexidade interna dos clientes. Proxy reverso para transporte, API Gateway para as preocupações transversais, BFF para moldar a experiência de cada cliente: cada peça no seu lugar. O sucesso da borda se mede pela sua discrição: ela deve ser invisível quando funciona, nunca um gargalo quando o tráfego cresce, e jamais o lugar onde a lógica de negócio foi parar. Uma borda fina e confiável liberta os serviços para evoluírem, em vez de amarrá-los a um novo ponto central.
A entrada dos seus serviços virou uma bagunça ou um gargalo? Na ConstructorTI, desenhamos a borda de serviços com API Gateway e BFF no ponto certo, com autenticação centralizada, agregação eficiente e sem transformar a borda em monólito. Se cada cliente hoje conhece detalhes demais dos seus serviços internos, fale com a nossa engenharia e receba um diagnóstico da arquitetura da sua borda.