Skip to main content

Api Gateway

Antigamente tinhamos um sistema grande que fornecia tudo que era necessário, mais conhecido como Monolito. Todas as requisições eram enviadas para ele. Hoje em dia as coisas mudaram muito e dividimos isso em sistema menores chamados microserviços para ficar mais fácil desenvolver, testar, escalar, dividir responsabilidades e gerenciar permissões, melhorar a segurança, etc.

Cada microserviço tem sua própria API e dependendo de qual endpoint desta API for utilizado uma resposta será dada.

Overview sobre APIs​

As APIs (Application Programming Interfaces) são interfaces que permitem a comunicação entre sistemas, serviços ou aplicações. Existem diversos tipos de APIs, cada uma com características específicas que as tornam adequadas para diferentes cenários. Vamos detalhar os principais tipos:

  • REST (Representational State Transfer)

    • É o padrão mais utilizado atualmente. Baseia-se em recursos representados como URLs, com operações realizadas por métodos HTTP (GET, POST, PUT, DELETE).
    • Protocolo HTTP.
    • Utiliza JSON ou XML (principalmente JSON atualmente) como formato de dados.
    • Mais simples e mais utilizado.
    • Facilmente integrável com navegadores e frontends.
    • Menor performance em comparação a outros protocolos.
    • Não mantém uma conexão persistente.
    • Geralmente usados em APIs públicas, integrações web, aplicações móveis.
    • Utiliza um padrão para escrever chamado OpenAPI (Antigo Swagger). As definições podem ser escritas em JSON ou Yaml

  • gRPC (Google Remote Procedure Call)

    • Protocolo desenvolvido pelo Google que utiliza HTTP/2 para comunicação, com foco em performance. Adota uma arquitetura baseada em chamadas de método remoto.
    • Protocolo HTTP/2.
    • Vários formatos podem ser utilizados. Avro, Protobuf, MessagePack (Json em formato binário para melhorar a performance). Existem outros, mas são menos utilizados.
    • Alta performance (menor latência).
    • Suporte a streaming bidirecional.
    • Definição de contratos fortemente tipados. Por exemplo um JSON não define se true deve ser lido como string ou booleano.
    • Complexidade maior em comparação ao REST.
    • Não é amigável para navegação direta em browsers.
    • Mais usados em microsserviços, comunicação entre sistemas de alta performance.

  • GraphQL

    • Linguagem de consulta para APIs criada pelo Facebook, que permite ao cliente especificar exatamente quais dados ele precisa.
    • Protocolo HTTP.
    • JSON é o formato de dados utilizado.
    • Permite consultas personalizadas, reduzindo sobrecarga de dados.
    • Ideal para aplicações que consomem APIs com múltiplos clientes (como web e mobile).
    • Maior curva de aprendizado.
    • Possibilidade de consultas excessivamente complexas, impactando a performance.
    • Mais utilizado em aplicações com frontends dinâmicos, projetos com grande variedade de clientes.

  • SOAP (Simple Object Access Protocol)

    • Um padrão mais antigo que utiliza XML para troca de mensagens estruturadas. Geralmente vai encontrar isso em sistemas legados.
    • Pode operar sobre os protocolos HTTP, SMTP, TCP.
    • Altamente padronizado e confiável.
    • Inclui especificações robustas para segurança e transações.
    • Muito verboso por usar XML tornando-o mais lento e pesado.
    • Menos flexível que REST ou GraphQL.
    • Sistemas legados, integração em bancos, serviços financeiros.

  • WebSocket

    • Permite comunicação bidirecional em tempo real entre o cliente e o servidor por meio de uma conexão persistente.
    • Protocolo WebSocket.
    • Texto ou binário podem ser utilizado nos dados.
    • Ideal para aplicações em tempo real.
    • Menor latência por manter conexões abertas.
    • Mais difícil de escalar em comparação com REST.
    • Requer suporte específico no servidor.
    • Usado em Chat, jogos, atualizações em tempo real.

Uma coisa que deve ser claro antes de começar é que Api Gateway não é balanceador de carga.

alt text

Funções do API Gateway​

Podem existir microserviços utilizando diferentes tipos de API, e como você vai saber quais onde estão cada um dos seus microserviços?

Vai utilizar um Balanceador de carga para agrupá-los? Vai separar pelo IP? Por subdomínio? Vai usar um service discovery? Como vai fazer a autorização deles? Como padronizar isso?

O Api Gateway vem para ser o muro, o hub, para todas essas APIs sendo o frente para o mundo interno do seu sistema que pode esta dividido de várias maneiras e ninguém precisa saber como. Com ele conseguimos simplificar um sistema complexo e ter controle sobre as requisições.

Um API Gateway é muito poderoso e tem muitas funções que podemos explorar.

alt text

Com um API Gateway temos somente um endpoint e ele encaminhará (função de roteamento), modificando se necessário (transformação), a mensagem para o API (microserviço) correto. Funciona como uma interface sobre interfaces (APIs).

Quando falei que ela pode modificar, quero dizer que as vezes queremos receber uma msg em JSON ou Yaml pelo API Gateway e ele mudará para XML para enviar a um microserviço legado que ainda não foi atualizado. Dessa forma conseguimos padronizar as coisas.

Quem esta de fora não sabe nem quantos microserviços estão sendo utilizados, nem conhece a API desses microserviços, somente aquilo que é exposto no API Gateway. Eventualmente eles pensam que você esta trabalhando com um único sistema.

Com Api Gateway podemos centralizar o processo de autenticação de autorização em um único ponto de entrada evitando que cada microserviço tenha que implementar individualmente. Dessa forma podemos garantir a uniformidade neste padrão de autenticação ou até mesmo mudar de forma centralizada evitando que seja corrigido isso em 300 microserviços.

O uso do Api Gateway melhora a segurança, pois cada linguagem utilizada nos diferentes microserviços tem bibliotecas específicas que implementam a autenticação e autorização. Evitando utilizar essas bibliotecas reduzimos a chance de sermos expostos a CVEs e delegamos esse problema para a cloud.

O API Gateway pode ser configurado para verificar e validar tokens de autenticação (como JWT) antes de permitir o tráfego para os microsserviços. Isso garante que os microsserviços nunca tenham que manipular diretamente as credenciais ou tokens sensíveis.

Ele tem suporte a vários provedores de autenticação diferentes o que simplifica a gestão de autenticação quando você tem usuários de diferentes fontes. Além disso pode ser utilizado para verificação de autorização baseado em RBAC ou ABAC permitindo um gerenciamos mais simples e coeso das permissões.

Existem muito mais coisas que podemos falar sobre um API Gateway, no quesito escalabilidade, flexibilidade, gerenciamento de sessão, etc.

O API Gateway deve ser usado quando trabalhamos com diferentes sistemas, não somente microserviços, e precisamos de um ponto único de entrada. Ele funciona como um proxy reverso turbinado e quando temos todas as requisições entrando por um único lugar também fica mais fácil de monitorar conseguindo ter uma visão macro de todo fluxo de entrada e saída (quantidade de requisições, endpoints mais acessados, stress extra por endpoint, tempos de resposta, etc)

Dois pontos importantes é que a API Gateway também tem o seu sistema de cache e versionamento que podem ser explorados para facilitar no desempenho e desenvolvimento.

Alguns serviços nem possui IPs como por exemplo os serverless (lambda na aws, function na azure, etc) e podemos fazer o uso da Api Gateway para dar a essas funções endpoints.

Outra funcionalidade interessante é incorporar um WAF no Api Gateway para proteção contra ataques de DDOS podendo criar regras que limitem o acesso à endpoints, por exemplo definir uma quantidade de requisições por segundo vindas do mesmo IP. Geralmente esses WAFs também nos ajudam a proteger contra outros tipos de ataque como SQL Injection.

Ainda podemos usar o Api Gateway para fazer a verificação dos schemas das evitando entregar um request sem os dados necessário para o próximo serviço melhorando o desempenho do sistema. Da mesma forma podemos fazer o tratamento de error e retornar uma reposta consistente caso backend não responda.

Ainda temos a opção de criar um endpoint que encadeia chamadas para vários backends e retornamos uma uma resposta única. É possível fazer mas pouco usual.

Vantagens​

  • Desempenho
  • Simplificação do sistema e das integrações
  • Escalabilidade
  • Segurança
  • Monitoramento

Desvantagens​

  • Ponto único de falha
  • Latência se não for bem trabalhado
  • Escravização por ficar preso nos recursos oferecidos e preços
  • Custo quando o tráfego é muito alto
  • Custo de Manutenção (Pessoal) principalmente se for hospedado.
  • Complexidade de configuração

Serviços Disponíveis​

Para as Clouds temos os serviços oferecidos:

  • Amazon API Gateway
  • Azure Api Management
  • Google Cloud Api Gateway
  • Apigee

Self Hosted Mais usados

  • Kong (Open Source)
  • Nginx Plus (Tem licença)
  • Express Gateway
  • Tyk

Se não quisermos utilizar o API Gateway da Cloud até por questão de preço temos uma ótima opção que é o Kong. Realmente é necessário fazer uma análise do custo disso pois muitas vezes a própria chamada para um serverless pode custar mais caro do que a execução da função.