Disponibilizando serviços por meio de API Proxies

Com a acirrada competitividade e as altas demandas do e-commerce brasileiro, os times precisam entregar funcionalidades de forma rápida e escalável para a continuidade do negócio.

Dentro do Luizalabs em geral, disponibilizamos features por meio de APIs REST para os canais (mobile, site etc) e outras aplicações consumirem de forma transparente.

Uma das maneiras que utilizamos para expor serviços para times é por meio de APIs dentro de proxies na plataforma Apigee Edge, adquirida pela Google em 2016.

Caso queira se aprofundar mais sobre a plataforma, segue o link para o site oficial: https://apigee.com/

Este artigo visa demonstrar de que maneira trazemos benefícios ao negócio com a disponibilização de recursos por meio de proxies (ou API Gateways), além de trazer uma breve introdução e entendimento superficial de alguns conceitos embutidos na plataforma.

Quais as vantagens de disponibilizar serviços via API Gateways?

É uma boa pergunta. Disponibilizando funcionalidades por meio de proxies dentro da apigee nos traz uma série de benefícios. As vantagens a se destacar são:

  • Melhor governança para as aplicações: Utilizando a apigee, temos um controle administrativo mais centralizado de permissões para o que um usuário pode fazer.
  • Recursos adicionais prontos: Ao entregar um serviço via proxy, é possível implementar muitos recursos essenciais para uma aplicação rodar em produção. Vale citar: distribuição de requisições para os servidores, segurança, cache entre outros de forma simples (também conhecido por policies). Graças à estes recursos, o tempo de desenvolvimento cai consideravelmente e não precisamos reinventar a roda.
  • Deploy : A plataforma permite realizar deploys via interface gráfica, apenas com um clique e alguns minutos de espera. O versionamento é feito automaticamente (por meio de “revisões”, o qual a cada deploy a versão é incrementada em 1) e não há downtime durante o processo: a aplicação continua recebendo e respondendo requisições normalmente.
  • Monitoramento: É possível criar dashboards de forma simples para acompanhamento de diversas métricas essenciais de uma aplicação como: quantidade de requisições, tempo de resposta, taxa de erros e dentre outros. Também é possível enviar logs para algum sistema de monitoramento (porém, é necessário criar esse mecanismo via código).
  • Debug: A plataforma oferece um trace no qual é possível acompanhar tudo que é realizado no fluxo: desde o momento que a requisição chega ao proxy até a resposta enviada ao cliente. Consequentemente, conseguimos identificar problemas e atuar mais rapidamente.
  • Desacoplamento entre aplicações: se você já ouviu falar do design patternfacade”, os proxies seguem essencialmente a mesma ideia: o proxy no caso é a “fachada”, pois esconde inúmeras complexidades que estão sendo feitas por trás dos panos, evitando que o cliente tenha que interagir com diversos outros sistemas para obter o que precisa. Apesar da ideia essencialmente ser parecida com o design pattern, ele acaba recebendo outro nome: API Gateway. Vamos à um cenário mais real - imagine que determinado canal/cliente precise de duas funcionalidades: dados de um determinado de um consumidor cadastrado para realizar recomendações de produtos. Porém, cada um desses domínios representam dois microserviços separados (cliente / recomendacão de produtos). Com a utilização do proxy, isso fica transparente para quem está consumindo: será necessário apenas enviar uma requisição ao proxy que o mesmo fará toda a mágica!
Exemplo de “fachada”: Os clientes realizam uma requisição para o proxy e por trás, são enviadas diversas requisições para microserviços e realizados outros processos antes da resposta ser entregue.

Vale ressaltar que não utilizamos a apigee somente para entrega de novos microserviços.

Também estamos conseguindo diminuir consideravelmente a dependência de canais e outros sistemas com os legados monolíticos.

Dentro do proxy, podemos converter uma resposta para quem ainda depende de coisas que o somente o sistema legado oferece. O proxy ,por baixo dos panos, envia requisições para microserviços desenvolvidos mais recentemente que contemplam as funcionalidades necessárias, porém que não mantém compatibilidade com os legados.

Durante o fluxo de request/response, é possível manipular grande parte das informações tanto da requisição quanto da resposta. Então, transformamos todo o conteúdo para o que o cliente espera: exatamente igual à resposta do sistema antigo.

Como já foi dito, todos esses recursos facilitam muito o desenvolvimento e disponibilização das funcionalidades em menos tempo.

A seguir será explicado alguns conceitos básicos da plataforma apigee em si.

Flows

Nos proxies, utilizamos flows para controlar os passos que devem ser executados de acordo com a requisição ou determinadas condições (como rotas, querystring, dentre quaisquer outras condições). É por meio destes que determinamos qual será o comportamento e os passos (policies) a serem executadas.

Um proxy pode ter diversos flows.

Policies

As policies adicionam funcionalidades já nativas da plataforma sem a necessidade de escrever uma linha de código sequer.

Elas são passos que serão executados dentro do flow e são configurados via arquivo XML.

Por exemplo, pode-se implementar uma policy que adicione segurança em um por meio do OAuth2 em questão de minutos. Isso independentemente se a API que está sendo disponibilizada via proxy possui OAuth implementado ou não. Outro exemplo: pode-se implementar policies para fazer requisições externas à outras APIs que não estão mapeadas como backend para o proxy.

Também pode-se criar policies para executar um código javascript que modifique ou acesse qualquer conteúdo da requisição/resposta antes de ser enviada ao cliente, por exemplo.

Conclusão

Vimos neste artigo que os times possuem diversos recursos que fazem sentido adotar a apigee para publicação de funcionalidades. Apesar do artigo focar nos pontos em que os times obtém vantagens competitivas, há também alguns a se atentar com a utilização de API Gateways via plataforma apigee.

Há um aumento de latência nas respostas se comparado à disponibilizar o serviço internamente, visto que se trata de um PaaS, não temos acessos às máquinas que a plataforma fica hospedada.

Por essa razão, alguns squads preferem apenas utilizar parte de seus recursos oferecidos tais como segurança e analytics. Não existe uma regra de que recursos adotar: tudo depende da necessidade e contexto de cada time.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.