Você sabe o que é um API Gateway, e quais principais características? Nesse artigo vamos ver exatamente isso, com um cenário de exemplo e com a análise de diversas características de um API Gateway e como elas podem contribuir para uma arquitetura mais segura, controlada e observável.

É muito comum que as empresas se conectem com seus parceiros e clientes através de APIs. Este tipo de comunicação deve ser tratado com muita atenção, pois é importante para quem está expondo seus serviços garantir questões como:

• Controle de tráfego
• Segurança
• Observabilidade.

Com o boom da arquitetura de microsserviços, isso se tornou mais evidente uma vez que as empresas passaram a expor diversos serviços para seus parceiros. Aquele monolito com as regras de negócios centralizadas deu lugar a uma malha de serviços com responsabilidades específicas, tornando mais complexo o gerenciamento da aplicação.

O API Gateway é a ferramenta que ajuda a reduzir esta complexidade, fornecendo recursos que podem fazer parte da estratégia de software, assumindo responsabilidades e permitindo que a aplicação seja desenvolvida com foco maior na regra de negócio.

Em uma definição simples, um API Gateway é uma ferramenta de gerenciamento de APIs que fica entre o cliente e o servidor (backend) que intercepta todas as requisições e pode aplicar políticas na entrada (request) e na saída (response).

Cenário de exemplo

Vamos considerar um cenário de uma plataforma que fornece serviços de e-commerce e que possui 3 microsserviços: Carrinho, Catalogo e Pedidos. Esta plataforma é fornecida por assinatura e possui diversos clientes conectados a ela. Quando um arquiteto está projetando uma aplicação deste tipo, há várias preocupações como:

• Como controlar o acesso as aplicações?
• Como monitorar estas aplicações?
• A Implementação de cache no catálogo para entrega rápida deve ser feito na aplicação?
• Como garantir que os clientes acessem as 3 aplicações com a mesma autenticação?
• Como vou identificar o problema se ocorrer uma falha?

Estas são algumas das preocupações, e se ignorarmos a existência de um API Gateway cada uma destas preocupações são triplicadas, considerando que estas responsabilidades devem ser atribuídas a cada uma das aplicações. Isso aumentaria a complexidade de desenvolvimento e, consequentemente, o custo do projeto.

Se o API Gateway fizer parte da estratégia da aplicação, algumas responsabilidades podem ser centralizadas diminuindo a necessidade de codificação e desta forma há redução de complexidade e custo de projeto.

Acesso por um único ponto

Se a plataforma de serviços de e-commerce tem 3 serviços é bem interessante que os clientes possam conectar suas aplicações a um único local, até porque no futuro outros serviços podem ser fornecidos.

Há diversas vantagens em um ponto de acesso único, tanto para o cliente quanto para quem mantém a plataforma.

O cliente não precisa se preocupar em configurar diversas conexões na aplicação e gerenciar diversas credenciais.

Já para quem mantém a plataforma, é possível:

• Realizar roteamento entre os serviços
• Aplicar políticas de segurança de forma global
• Configurar throttling para não ter abusos
• Configurar detecção de bots
• Criar correlation id e repassar para as aplicações
• Gerar logs de requisição

Com estes recursos, o arquiteto já pode pensar em reduzir a complexidade das aplicações, delegando estas responsabilidades ao API Gateway.

Roteamento entre os serviços

Quando a requisição chegar ao API Gateway, ela deverá ser redirecionada por ele a um serviço específico. Para fazer isso, uma política de rotas pode ser definida onde, por exemplo, a url https://api.ecommerce.com.br/carrinho/ direciona a aplicação para o serviço de carrinho, /pedidos para pedidos e /catalogo para catálogo. Assim, o cliente tem um ponto de acesso único e uma visão transparente da aplicação.

Este cenário pode ficar ainda mais interessante considerando que os serviços podem ser versionados, como por exemplo os caminhos /v1/carrinho ou /v2/carrinho que direcionam para versões específicas. Se considerar APIs de nível de maturidade 3, o versionamento pode ser feito diretamente pelo cabeçalho no próprio API Gateway.

Além de rotear para os serviços, as rotas podem ser reescritas. Se a aplicação foi construída com as rotas em português mas por uma estratégia da empresa, a exposição tem que ser feita em inglês, é possível criar rotas que mapeam para os endpoints internos. Por exemplo, uma requisição a /orders/approve poderia direcionar internamente para /pedidos/aprovar.

Segurança

Como o API Gateway fica entre o cliente e o backend é interessante que ele seja responsável por cuidar da segurança das aplicações. A vantagem em fazer isso é que tanto a autenticação do usuário, quanto a autorização de acesso aos endpoints atuarão no tráfego ao backend, poupando recursos da aplicação.

Autenticação e autorização

A implementação de autenticação pode ser feita por usando mecanismos mais simples, como uma API Key, ou mecanismos mais complexos e mais seguros, como OAuth. No caso de OAuth, o API Gateway pode fazer o papel de provedor de identidade ou pode simplesmente validar se o token JWT é valido, confiando em um provedor externo. Tendo o token validado, o API Gateway pode determinar se a aplicação poderá ou não ter acesso a determinado recurso.

Levando em consideração o cenário da plataforma de ecommerce, é possível que uma aplicação tenha permissão para fazer uma requisição de leitura a um endpoint (GET) do serviço de Catálogo mas não para modificação, recebendo um retorno de proibido (403) caso tente realizá-la.

Apesar das linguagens de programação terem recursos que permitem fazer este tipo de autorização de forma simples, fazer este procedimento no API Gateway evita que a requisição seja processada pelo backend. Em caso de um ataque por excesso de tentativas, o backend fica protegido e não há sobrecarga do recurso.

Restrição por IP

Um recurso que permite criar uma relação de confiança entre a aplicação e o cliente é a restrição por IP. Desta forma, o API Gateway só vai processar requisições se o IP de origem for permitido. No caso da plataforma de e-commerce, quando os clientes por assinatura quiserem usar a plataforma deverão informar o IP de origem das requisições. Se por algum motivo aconteceu o vazamento das chaves de autenticação, o ofensor será barrado pelo IP, criando assim mais uma camada de segurança.

Deteccão de Bots

Geralmente os ataques são feitos por mecanismos conhecidos como ferramentas de testes de APIs e bibliotecas de linguagens de programação. Desta forma, o API Gateway pode aplicar regras para identificar estes bots e negar o acesso ao endpoint. Se o ofensor tentar criar uma automação usando curl por exemplo, o API Gateway pode negá-lo. Além disso, os clientes da plataforma de e-commerce tem a possibilidade de criar uma exceção para sua aplicação.

Estas formas de segurança geralmente são simples de configurar em um API Gateway, porém seriam bem complexas de ser desenvolvidas por conta própria, possivelmente cobrindo uma quantidade de cenários inferior.

Controle de Tráfego

É importante controlar como os dados estão chegando e saindo dos nossos serviços, pois desta forma é possível limitar as aplicações e fornecer recursos que ajudam a melhorar a performance e poupar recursos dos serviços.

Throttling

Mesmo que um cliente esteja autenticado, isso não vai garantir que ela esteja fazendo bom uso da API. Pode acontecer do cliente fazer mais requisições que o necessário, comprometendo a infraestrutura em casos extremos.

Como ação preventiva, o recurso de throttling pode ser aplicado no API Gateway. Este recurso vai limitar a quantidade de requisições que uma aplicação pode fazer em um período de tempo.

No caso da plataforma de e-commerce, pode ser uma boa idéia limitar o cliente de acordo com planos de assinatura. Um plano básico pode permitir que sejam feitas 50 requisições por segundo ao serviço de catálogo, enquanto o plano mais avançado pode permitir 3000 requisições por segundo. Se a plataforma tiver uma sandbox, não é interessante que o número de requisições seja muito alto, pois este é um ambiente de validação, podendo ter um limite de 3 requisições por segundo. Se os limites forem ultrapassados, o API Gateway automaticamente começaria a responder com mensagem de erro e status 429 até que o novo ciclo de consumo se inicie.

Cache

Adicionar cache a aplicação é uma estratégia interessante pelo seguinte comportamento:

• O backend responde a primeira requisição, e as seguintes são respondidas diretamente pelo API Gateway até que o cache expire;
• Logo, como não há processamento, a entrega da requisição em cache é mais rápida.

Este tipo de estratégia pode ser usado quando os dados não tem mudanças constantes.

Mas é necessário ter um questionamento: o que acontece quando o valor foi atualizado no backend e mas já estiver no cache do API Gateway? Este é um cuidado que deve ser tomado para não entregar dados desatualizados a aplicação. Uma forma de resolver isso é invalidar o cache quando a informação é atualizada. Caso o tempo de atualização não seja crítico para a regra de negócio, o cache pode ser invalidado automaticamente após a expiração.

A plataforma de e-commerce pode ter o catálogo em cache, e quando tiver uma atualização de produto, o cache deve ser invalidado para que os dados sejam atualizados. Esta é mais uma estratégia que poupa tráfego do backend.

Observabilidade

O serviço está seguro e tem o tráfego controlado, mas como ter certeza disso? O API Gateway pode fornecer informações sobre o ambiente, sobre a dados das requisições e rastreios dessas até os serviços. Estas informações são importantes para a tomada de decisões, já que quem controla as aplicações necessita saber quanto de recurso está sendo utilizado para manter as aplicações no ar, assim como precisa ter informações para diagnosticar e resolver possíveis problemas.

Métricas

A partir do momento que um API Gateway está no meio do caminho entre o cliente a aplicação, é importante entender que há um possível ponto de falha e de latência que precisa ser monitorado. O API Gateway vai adicionar um leve tempo à requisição e isso precisa ser metrificado e comparado com o tempo que o backend responde. Em um momento de troubleshooting esta informação é necessária para identificar onde está o problema.

O API Gateway pode fornecer informações que compõem o The Four Golden Signals, que resumidamente são:

• Latência: tempo de duração de uma requisição entre o gateway e o backend e o tempo total da requisição (processamento no API Gateway somado ao tempo de resposta ao backend)
• Saturação: qual o percentual de recursos o seu API Gateway está consumindo (memória, CPU e I/O)
• Erros: quantos erros estão ocorrendo no retorno das aplicações
• Tráfego: quantas requisições estão passando pelo API Gateway

Se os clientes começam a reclamar que estão com lentidão no serviço de pedidos, recorrer a estas métricas vai permitir identificar de forma rápida onde está o problema. Se nas métricas apontar que o tempo de processamento do API Gateway é 500ms enquanto o backend responde em 10ms, ações devem ser tomadas no API Gateway. Outros dados permitirão tomar uma decisão sobre o que fazer. Por exemplo, se a saturação está alta indica que as configurações podem ser revisadas com o intuito de identificar o uso indevido de recursos ou o API Gateway necessita de mais recursos para funcionar.

Logs

Os logs do API Gateway irão dar informações suficientes para realizar a identificação de quem fez a requisição, o tempo que durou, a URL chamada, os headers recebidos e enviados, o método que foi utilizado, o código de status, entre outras informações.

Um cliente pode reclamar que está recebendo mensagem de erro NOT FOUND e não está entendendo o que está acontecendo. Uma pesquisa nos logs pode mostrar que ele está tentando acessar o recurso incorreto. Se estiver acontecendo de uma aplicação retornar o erro SERVER ERROR esporadicamente, o log pode mostrar que este problema está ocorrendo em uma rota específica ou com parâmetros específicos.

Tracing

O API Gateway pode auxiliar a propagar informações de tracing entre as aplicações e reportar a um servidor específico. Desta forma, é possível ter o ciclo de vida completo de uma requisição. Porém, vale destacar que se uma aplicação faz tráfego leste-oeste com outra aplicações, ela deve ser responsável por trafegar estas informações. Em um momento de falha de requisição, ter o tracing da requisição ajuda a identificar onde a cadeia se quebrou.

Se um cliente da plataforma de e-commerce reclamar que os pedidos não estão sendo finalizados, consultar o tracing das últimas transações dele pode mostrar onde o processo foi interrompido.

Desafios em manter um API Gateway

Ter um API Gateway indica ter um ponto crítico entre a sua aplicação e o mundo externo. Se o API Gateway parar, todas as sua aplicações ficam inacessíveis. Considere:

• Ter uma estrutura redundante que faça um fallback em caso de falha. Um API Gateway dividido em vários ambientes pode ajudar nisso.
• Se o API Gateway adicionar latência que atrapalhe a regra de negócios, deve-se analisar os recursos que estão sendo utilizados, e possivelmente realizar ajustes de configuração ou aumento de recursos para resolver o problema.
• Ser crítico ao adicionar e atualizar funcionalidades e configurações ao API Gateway. Uma configuração incorreta pode deixar as aplicações fora do ar.

---

Quer alavancar sua carreira como Desenvolvedor(a) .NET?

Opa, aqui é o Luis Felipe (LuisDev), criador do blog LuisDev.

Além de Desenvolvedor .NET Sênior, eu sou instrutor de mais de 700 alunos e também tenho dezenas de mentorados.

Conheça o com mais de 800 video-aulas sobre C# e desenvolvimento de APIs com ASP NET Core, Microsserviços com ASP NET Core, Arquitetura de Software, Computação em Nuvem, SQL, HTML, CSS e JavaScript, JavaScript Intermediário, TypeScript, Desenvolvimento Front-End com Angular, e Desenvolvimento Front-end com React. Diversos mini-cursos disponíveis aos alunos e atualizações gratuitas.

Suporte dedicado, e comunidade de centenas de alunos.

Completo e online, destinado a profissionais que querem dar seu próximo passo em sua carreira como desenvolvedores .NET.

Clique aqui para ter mais informações e garantir sua vaga

---

Conclusão

Muitas funcionalidades podem ser delegadas ao API Gateway, permitindo que os desenvolvedores foquem nas regras de negócio. Além disso, o acesso centralizado aos serviços fornece uma melhor experiência aos clientes, além de um melhor controle das aplicações nos diferentes aspectos tratados neste artigo.

Insights de Ferramentas

A maior parte dos API Gateways podem ser conectados a outras ferramentas para executar suas funções.

API Gateway:

• Kong
• Zuul

Observabilidade:

• Grafana, Kibana – visualização dos dados em forma gráfica
• Prometheus – coleta de métricas
• Zipkin e Jaeger – tracing de requisições
• ElasticSearch – armazenamento de logs

Cache

• Redis