[Krakend] API Gateway — Agregando e modificando responses

Hoje muito se fala sobre arquiteruta orientada a microsserviços, na qual, sendo bem simplista, zelamos pela divisão dos serviços para que tenham uma responsabilidade bem definida e o máximo de independência de outros microsserviços, tentado reduzir ao máximo o acoplamento entre eles.

Num cenário como o descrito acima, onde cada serviço gerencia dados de uma parte específica do negócio e disponibiliza essas informações por alguma interface, nesse caso de estudo WEB API, é muito comum precisarmos buscar informações em vários locais para compor todas as informações que necessitamos para realizar alguma atividade, seja exibição das informações no frontend ou a utilização desse conjunto de dados para o processamento de qualquer regra de negócio.

Esse overhead, de buscar a informação em várias fontes, trago pela arquitetura de microsserviços pode ser atacado de algumas formas, neste artigo veremos como podemos resolver esse problema com a utilização de um Api Gateway, no caso o Krakend.

Api Gateway?

Api gateway é um componente situado entre o cliente e um conjunto de serviços, ou seja, ele recebe todas as requisições e define como isso deve ser atendido e qual ou quais serviços do backend devem ser acionados. Importante dizer que com a utilização de um Api gateway, muitas responsabilidades são abstraídas do backend pois poderão ser atendidas pelo gateway, algumas:

• Rate limit
• Monitoração
• Proxy
• Agregação de requests

Krakend

Krakend é um api gateway open source que tem como funcionalidade core a capacidade de realizar agragações, transformações, filtros e alguns outros recursos conforme descrito em sua documentação:

Introduction to KrakenD

Nesse artigo vamos abordar a capacidade de agregar e modificar responses, sem a necessidade de implementação, ou como a propria documentação diz, “KrakenD needs no programming as it offers a declarative way to create the endpoints”.

Cenário proposto

Para a ilustração dos exemplos a seguir vamos trabalhar em um cenário em que temos dois microsserviços responsáveis por expor informações de usuários.

Um serviço será responsável por expor informações do usuário, como id, first_name, last_name, email e address. Para a demonstação criei uma api node para disponibilizar esses dados, conforme abaixo:

Exemplo de consulta de usuário:

Temos também um segundo microsserviço responsável por disponibilizar informações de pedidos realizados pelos usuários. A api abaixo representa esse serviço.

Consulta de pedidos por usuário

Dados os serviços expostos acima, vamos verificar como podemos configurar o api gateway para a agregação e modificação das respostas.

Iniciando Krakend

Como demonstrado nos itens anteriores, temos a api order-manager executando na porta 3001 e a api user-manager na porta 3000.

Para essa demonstração utilizaremos a imagem oficial do krakend, a documentação está disponível no link: https://hub.docker.com/r/devopsfaith/krakend/

A configuração desse api gateway é realizada utilizando arquivo json, na documentação oficial esse arquivo é referenciado como “krakend.json”, contudo podemos utilizar outra nomenclatura. Na imagem docker que utilizaremos precisamos realizar o mapeamento de um volume que contenha esse arquivo para o diretório do container onde o krakend carrega suas configurações. Dado que estamos com nosso terminal aberto no diretório onde criamos nosso arquivo “krakend.json”, podemos iniciar o krakend como comando abaixo:

Agregação de responses

É comum temos o cenário em que precisamos realizar várias consultas para compor o conjundo de informações necessárias para exibição em um fronted. Com as APIs que exibimos nos tópicos anteriores podemos imaginar a situação que precisamos exibir numa tela as informações do usuário e também a lista de pedidos desse usuário, por tanto devemos realizar uma busca da api user-manager (eu sei, sou péssimo com nomes), e outra consulta na api order-manager, ou podemos utilizar a função de agragação do api gateway. Vamos ver como podemos configurar o krakend para esse caso de uso.

Para efeitos didáticos, nesse exemplo vamos utilizar o arquivo de configuração do Krakend com nome agragacao.json.

Alguns itens que podemos observar no arquivo:

• Linha 4: definição da porta que o krakend realizará o bind
• Linha 7: array de endpoints disponível no krakend
• Linha 9: definição da rota, neste exemplo ficaria: http://{host}:8080/aggregation/users/{userId}/orders
• Linha 14: array de backends que o krakend realizará a busca das informações
• Linha 19: nome da propriedade do json que será incluso com os dados de retorno da api user-manager
• Linha 26: mapeamento do retorno da api oder-manager para o array orders

Para testarmos podemos executar o comando “docker run” no mesmo diretório em que reside o arquivo “agregacao.json”, conforme abaixo:

docker run -it — volume /$(pwd):/etc/krakend — add-host kubernetes.docker.internal:host-gateway -p 8080:8080 devopsfaith/krakend run -c agregacao.json

Realizando um GET na rota “http://{host}:8080/aggregation/users/161/orders” teremos o retorno abaixo:

Podemos observar que os pedidos do usuário foram adicionados ao array orders e as informações do usuário foram adicionados a propriedade user, e desta forma o cliente realizou somente uma chamada HTTP, podendo otimizar assim o processo.

Modificação de responses

A modificação do response pode ser útil em diversas situações. No nosso cenário das APIs de order e user vamos imaginar que precisamos exibir no frontend somente o nome do cliente, e neste caso por alguma razão o front não deve ter acesso ao demais atributos do usuário, poderíamos criar a configuração abaixo no krakend. Vamos utilizar o arquivo modificacao.json abaixo:

Itens que podemos observar no arquivo, apenas o que não foi visto no item de agragação:

• Linha 9: definição da rota, neste exemplo ficaria: http://{host}:8080/modification/users/{userId}
• Linha 19: lista de propriedades que devemos retornar parao cliente, independete se o backend retornar informações adicionais

Realizando um GET na rota “http://{host}:8080/modification/users/161" teremos o retorno abaixo:

Podemos observar que as demais propriedades do usuário não foram retornadas para o cliente.

Conclusão

A itenção desse artigo foi abordar duas funcionalidades básicas desse api gateway, contudo na documentação do krakend podemos verificar muitas outras funcionalidades importantes e os encorajo a darem uma olhada.

Abaixo deixo o link do github com todos os códigos demonstrados acima:
https://github.com/ElvisFDias/krakend-api-gateway

Espero ter contribuído, obrigado e até mais!