A importância de um API gateway para seu back-end

A importância de um API gateway para seu back-end


https://medium.com/design-microservices-architecture-with-patterns/api-gateway-pattern-8ed0ddfce9df

Introdução

Quando trabalhamos com arquitetura distribuída, várias preocupações e complexidades surgem no processo de desenvolvimento e na forma como as aplicações se comunicam. Como remover a complexidade das diferentes estruturas de contratos do back-end para o front-end? Como limitar as requisições que podem chegar no back-end? Como centralizar a autorização de consumo dos serviços? Para essas e outros problemas, a adoção de um API Gateway é certamente a solução adequada.

O que é um API Gateway?

Um API gateway é responsável por atuar como a porta de entrada das requisições de um consumidor para os serviços de back-end e é comumente utilizado em arquiteturas distribuídas.


O API Gateway tem por principais finalidades: Filtrar o tráfego, ser porta de entrada única para as APIs, atuar como Roteador, limitar requisições por meio de Rate Limit, facilitar mecanismos de segurança.


Alguns dos principais benefícios na utilização de um API Gateway são:

  • Única entrada para o back-end

  • Detalhes e fragilidades ficam internos

  • Camada adicional de segurança para o back-end

  • Complexidade com diferentes protocolos não é repassada para o front-end

  • Simplifica os testes por separar a interface do front-end do back-end

Única entrada para o back-end

Ter várias APIs para gerenciar, por si só já é complexo e se tivermos de implementar aplicações de front-end, BFFs ou qualquer outro cliente que consuma esse back-end, o trabalho se torna ainda mais complexo. Imagine uma aplicação de ecommerce que precisa se comunicar com um serviço de checkout, de busca, de produtos, e muitos outros. O front-end (cliente) que irá se comunicar com esses serviços terá de armazenar todas as URLs dos serviços de back-end, conhecer os padrões de rota e gerenciar esses padrões, além de lidar com diferentes tokens para autorização o consumo desses serviços e implementar muitos recursos de resiliência. A solução para remover toda essa complexidade é centralizar as requisições em apenas um serviço e esse serviço se comunicar com os demais serviços, simplificando a forma como o front-end fala com o back-end, ou seja, adotar um padrão BFF resolve o problema, certo? Errado!

Um BFF é uma boa abordagem pois é possǘel otimizar a forma de consumo de serviços no front-end, mas ainda teríamos de lidar com a complexidade dos tokens de autorização, ou seja, para cada serviço teríamos um token de autorização e ainda teríamos de gerenciar isso no front-end e implementar autorização em todas os serviços de back-end. Então, colocando um API Gateway nessa solução e jogando o BFF para trás dele é possível implementar autorização apenas no API Gateway e ela seria única para todos os serviços de back-end.

Considerando as possibilidades com versionamento nos serviços de back-end, poderíamos formatar as rotas garantindo padronização para os consumidores (clientes), além de permitir desassociar a versão das rotas, das versões do serviços de back-end, ou seja, é possível ter um serviço que entrega a rota /v1 e /v2 e um novo serviço que usa outra tecnologia, também entregando a /v1, mas no API Gateway seria possível, por exemplo, servir em uma nova rota /v3.

A capacidade de implementar uma captura de log centralizada também é um benefício que vale destacar, evitando que tenhamos de implementar captura de logs das requisições que chegam aos serviços, em cada um deles.

Detalhes e fragilidades ficam internos

Diversas características dos serviços de back-end em uma arquitetura distribuída podem ser isoladas do mundo exterior, um exemplo rápido é o versionamento já mencionado anteriormente. Mas podemos ir além, não é preciso, por exemplo, implementar autorização nos serviços de back-end, é possível deixar essa responsabilidade apenas para o API Gateway e internamente os serviços teriam permissão de se comunicarem abertamente (a depender das restrições arquitetônicas). Outra possibilidade é a capacidade de internamente consumir os serviços de back-end  de forma ilimitada, enquanto externamente, via API Gateway, é possível limitar a quantidade de requisições (rate limit) que chegam nos serviços de back-end.

Se considerarmos uma arquitetura em processo evolutivo, composta por legados e serviços novos. Também podemos utilizar o API Gateway para servir para o front-end uma interface de consumo atendendo às características configuradas nos serviços de back-end mais novos e internamente o processamento seria feito por um sistema legado que poderá ser reestruturado no futuro.

Outra possibilidade apresentada por um API Gateway é a capacidade de executar re-tentativas (padrão retry) nas chamadas feitas aos serviços de back-end. Poderíamos  além de usar no front-end o padrão retry, também implementar no API Gateway, dessa forma a requisição já estaria dentro da rede privada e seria muito mais eficiente do que deixar apenas que o front-end cuide das re-tentativas e falhas.

Camada adicional de segurança para o back-end

Um API Gateway permite não apenas servir uma camada única de autorização (e até autenticação), mas como já mencionado, permitir liminar a quantidade requisições (rate limit) que chegam nos serviços de back-end, e essas requisições, quando atingem o limite proposto, param antes mesmo de chegar no serviço de back-end (são represadas no próprio API Gateway).

Um API Gateway também permite integração com serviços de apoio, como por exemplo um motor de risco, ou qualquer outra solução que faça análise das requisições e tente prever se essa requisição é maliciosa ou não, evitando comprometer os serviços de back-end.

Complexidade com diferentes protocolos não é repassada para o front-end

WSL, RPC, HTTP, HTTPS e qualquer outro protocolo que possa existir no back-end, todos eles podem ser simplificados para o front-end consumidor, ou seja, é possível trabalhar apenas com HTTPS no consumidor, enquanto o API Gateway se preocupa em fazer a requisição de acordo com o protocolo do serviço de back-end.

Simplifica os testes por separar a interface do front-end do back-end

Apresentado todos os benefícios acima, é possível concluir que, por estarmos centralizando as chamadas, conseguimos também utilizar o API Gateway para servir respostas “mockadas”, por exemplo, trazendo a capacidade de fazer testes completos no front-end sem a preocupação de estar interagindo com o back-end real.


Implementar ou usar um API Gateway?

A menos que exista alguma restrição que invalide a utilização de um API Gateway de mercado, como o Zuul (que oferece roteamento dinâmico, monitoramento, resiliência e segurança para os serviços de back-end do Netflix) ou o Kong (grande capacidade de escalabilidade, performance e extensível via plugins), certamente utilizar API Gateways já consolidados é a melhor alternativa.

Referências