Com o aumento considerável do uso dos conhecidos cloud providers, alguns tópicos que eram restritos ao vocabulário dos profissionais de infraestrutura acabaram transbordando para outras áreas, em especial para os times de desenvolvimento. Um destes termos é o API Gateway.
Afinal, você saberia descrever para que serve este componente? Bem, se fosse possível achar um exemplo do nosso cotidiano que se assemelhasse às atividades e responsabilidades de um API Gateway, uma boa sugestão seria o contexto de uma portaria de um prédio empresarial.
Imagine que você é um fornecedor de uma empresa que está neste prédio e que você precisa entregar um pedido. Nesse cenário, dependendo da portaria, você:
- Não terá acesso direto à empresa em questão;
- Você terá de interagir com um intermediário (um(a) recepcionista por exemplo)
- Caso você precise se dirigir até o andar da empresa, a recepcionista irá fazer algumas confirmações com empresa por motivos de segurança;
- Além dessas confirmações, para entrar no prédio você receberá um cartão de acesso que permite apenas acessar o andar da empresa em questão;
Se convertermos o cenário da portaria do prédio para um cenário de uma aplicação web qualquer, as empresas seriam as APIs, a encomenda seria uma requisição HTTP, e a portaria seria o API Gateway.
Essas responsabilidades relacionadas ao isolamento, controle de acesso e ser um intermediário entre as requisições definem o escopo de atuação de um API Gateway:
– Isolamento: as requisições HTTP nunca chegam diretamente ao serviço, o API Gateway tem a responsabilidade de recebê-las e redirecionar para o serviço correspondente de forma transparente.
– Proxy Reverso: para o solicitante, as respostas das requisições se apresentarão como do próprio serviço; no entanto, o API Gateway é que estará se passando de serviço realizando os redirecionamentos, tanto de requisição como de resposta.
– Autenticação: é possível delegar ao API Gateway a camada de autenticação e acesso para as APIs em questão, sendo capaz de implementar o fornecimento de tokens, ou até mesmo cenários do protocolo Oauth 2.0.
Mas como tudo no mundo de TI há um preço, ao implementar um API gateway à frente de suas APIs, tenha em mente que:
1. Adição de um elemento na sua infraestrutura – aumento de complexidade e manutenção ;
1. Dependendo do tipo de implementação, o API Gateway poderá ser um ponto único de falha, ou seja, caso ele falhar, nenhuma aplicação conseguirá acessar às suas APIs;
1. Aumento de latência, haja vista que para cada requisição será obrigatório a passagem pelo API Gateway, e o mesmo será responsável por redirecionar a requisição, coletar a resposta e devolver ao remetente de forma transparente;
No mundo Open Source podemos destacar três ferramentas que visam resolver esse tipo de problema. O primeiro é o Kong – derivado do famoso _NGINX_, que estende suas características para atuar como um API Gateway. O segundo que vale menção é o KrakenD, que além de atuar como API Gateway, foi construído para ser escalado, ou seja, não sofrer do mal de ser um single point of failure. Por fim, o Traefik também pode ser considerado um API Gateway – desenvolvido em GO, além dessas responsabilidades já citadas, se destaca por ter uma funcionalidade de service discovery automático, ou seja, identifica as APIs de sua infraestrutura sem precisar de esforços de configuração, além de possuir esse comportamento de forma dinâmica – assim sendo, se algum serviço ficar indisponível ou adicionarmos novas APIs em nossa infraestrutura, ele é capaz de identificar tais status.
Nos cloud providers (como AWS, GCP, Digital Ocean, OCI, Azure entre outros), os API Gateways nos são apresentados como um produto da própria cloud, em geral, responsável por direcionar as requisições para as APIs ou, em arquiteturas _serverless_, para funções.
Artigo originalmente publicado por 4.Linux
DNX Brasil – Soluções cloud-native
