[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:
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!