Arquitetura de micro serviços em Node.js + MongoDB: Parte 5

E chegamos à quinta parte da nossa série de artigos sobre como implementar na prática um projeto de sistema usando arquitetura de microservices usando Node.js e MongoDB. Essa que já é uma das séries de artigos mais longevas aqui do blog!

Segue o índice da série até o momento, caso tenha caído de pára-quedas no blog só agora:

  • Parte 1: introdução teórica e case que estudaremos;
  • Parte 2: estrutura do projeto, camadas de dados e testes unitários;
  • Parte 3: primeiro microservice finalizado (movies-service);
  • Parte 4: iniciando desenvolvimento do segundo microservice (cinema-catalog-service);

Nesta quinta parte, vamos fazer o desenvolvimento das demais funções do repository.js do micro serviço cinema-catalog-service, lembrando que queremos fornecer através deste micro serviço acesso ao front-end mobile a funções como consulta de cinemas por cidade, de filmes em exibição por cinema, sessões dos filmes e por aí vai.

Consulta de Lançamentos do Cinema
Consulta de Lançamentos do Cinema

Veremos nesta etapa da série:

  1. Finalizando o Repositório
  2. Programando a API Cinema-Catalog-Service

Então mãos à obra!

#1 – Finalizando o Repositório

Onde paramos no artigo anterior? Ah sim, tínhamos a seguinte lista de funções a serem criadas no repository.js:

  • pesquisar cidades em que a rede possui cinema;
  • pesquisar cinemas por id da cidade;
  • pesquisar filmes disponíveis em um cinema;
  • pesquisar filmes disponíveis em uma cidade;
  • pesquisar sessões disponíveis para um filme em uma cidade;
  • pesquisar sessões disponíveis para um filme em um cinema;

Enquanto que as duas primeiras foram feitas ainda no artigo anterior, as demais não. Elas guardam uma complexidade que ainda não tivemos de lidar no nosso projeto: agregações. Como nosso documento é relativamente complexo, com mais de um nível de profundidade, se faz necessário navegar e agrupar dados entre os níveis para oferecer informação relevante e fácil de ser manipulada pela camada de API que ainda nem construímos.

Assim, abra o seu cinema-microservice/cinema-catalog-service/src/repository/repository.js e adicione a seguinte função:

Respire por um momento que aqui temos uma série de novos operadores e a novíssima função aggregate.

A função aggregate substitui a função find quando nossa consulta irá manipular os dados resultantes para realizar agregações de diversos tipos. A função aggregate executa um pipeline de comandos contidos no array que ela recebe por parâmetro, seguindo exatamente a ordem do array. Assim, do primeiro operador do nosso pipeline de agregação temos:

  • $match: este operador é um filtro, tal qual os possíveis de serem utilizados no find. Aqui, estou dizendo para filtrar apenas pelos documentos cujo id do cinema seja igual ao recebido;
  • $unwind: este operador desconstrói campos multivalorados em novos documentos, repetindo os demais dados do documento pai do array. Ou seja, se eu tinha uma cidade com dois cinemas dentro, o primeiro $unwind vai fazer com que eu tenha duas cidades repetidas, mas cada uma com um cinema apenas (o campo multivalorado vira univalorado);
  • os $unwinds seguintes vão desconstruindo os demais arrays do documento;
  • $group: uma vez que eu tenho todos os documentos com apenas documentos e subdocumentos (sem arrays), é hora de agrupar eles para evitar as repetições e também para pegar apenas os dados que me interessam, que são os ids e nomes dos filmes que estão em exibição no cinema em questão;

Essa agregação toda, no final das contas, gera um array de filmes no formato id/nome bem simples de ser recebido e utilizado pela API.

Na mesma linha da função anterior, vamos criar mais três delas, finalizando nosso repository.js:

Note que nestas funções ainda temos mais alguns complicadores.

Primeiro, todas elas estão tratando o retorno da função to Array para passar para o callback objetos mais “mastigados” uma vez que o operador $group do MongoDB costuma deixar um nível desnecessário dentro dos documentos que ele retorna, fora nomenclaturas e etc que podemos tratar melhor usando a boa e velha função ‘map’ do JavaScript.

Além disso, as duas últimas funções usaram um operador $match adicional para fazer um novo filtro após os $unwinds, diminuindo ainda mais a carga do operador $group. Usar o operador $match o quanto antes do final do pipeline de agregação é sempre uma boa prática para diminuir a carga da função aggregate que é bem pesada.

Para finalizar este arquivo, não esqueça de colocar o nome de todas funções no module.exports no final do mesmo:

E ‘bora criar novos testes unitários para cobrir estas novas funções no repository.test.js, como abaixo. Coloque estes testes após o teste da função ‘Repository getCinemasByCityId’ e antes do teste da função ‘disconnect’.

Isso nos dará uma cobertura de 100% das nossas funções, nos dando a garantia que podemos avançar para a camada de API do nosso microservice sem medo de ter deixado alguma ponta solta para trás!

Curso Node.js e MongoDB
Curso Node.js e MongoDB

#2 – Programando a API Cinema-Catalog-Service

 

Nosso próximo passo é criar a API propriamente dita. Seguiremos a mesma arquitetura da API anterior, a movies-service, apenas definindo um novo conjunto de rotas coerente com a responsabilidade desse microservice novo que é a localização de salas e sessões de cinema a partir de informações como cidade, filme, etc.

Baseado no que temos de funções em nosso repository.js, podemos definir que devemos fornecer o tratamento das seguintes rotas na nossa API:

  • GET /cities
    • lista todas cidades em que a rede possui cinema;
  • GET /cities/:city/movies
    • lista todos os filmes em exibição na cidade especificada;
  • GET /cities/:city/movies/:movie
    • lista todos as sessões do filme escolhido na cidade especificada;
  • GET /cities/:city/cinemas
    • lista todos os cinemas em determinada cidade;
  • GET /cinemas/:cinema/movies
    • lista todos os filmes em exibição no cinema especificado;
  • GET /cinemas:cinema/movies/:movie
    • lista todas as sessões do filme escolhido no cinema especificado;

Novamente vamos adotar a abordagem de não fazer o CRUD completo mas apenas as chamadas que possibilitem ao front-end poder construir suas telas e seu funcionamento de navegação.

Obviamente você pode pensar em rotas adicionais à estas ou até em uma ‘pureza’ maior do conceito de RESTful.

Com esse mapeamento das rotas em mente, vamos criar nosso arquivo cinema-microservice/cinema-catalog-service/src/api/cinema-catalog.js com o seguinte conteúdo que não tem nada demais em relação à API anterior que já criamos (movies-service):

Note que como o trabalho pesado ficou todo no repository.js e suas inúmeras agregações, aqui basta receber a requisição, pegar os parâmetros adequados e chamar a função correspondente no repositório. Simples assim.

Para escrever nossos testes, usaremos como base as mesmas ferramentas e princípios dos testes de API que fizemos na Parte 3 usando a biblioteca supertest como apoio (lembrando que instalamos todas as dependências deste projeto no artigo anterior). Assim, crie o arquivo cinema-catalog.test.js e adicione os seguintes testes dentro dele:

O que tem de novo aqui que valha a pena ser explicado? Absolutamente nada, e espero que a esta altura do campeonato você consiga criar este arquivo e seus testes sem ter de necessariamente copiar e colar este bloco inteiro de código. Caso ainda não consiga, tente ao menos copiar apenas um teste e escrever de próprio punho os demais, para ir pegando prática.

Para verificar se os testes estão funcionando, apenas adicione mais uma linha no nosso índice de testes:

Rode com um ‘npm test’ e se fez tudo certinho, verá uma beleza de bateria de testes tendo sucesso.

Todos testes OK
Todos testes OK

Para finalizar nosso micro serviço precisamos construir o nosso index.js que é praticamente idêntico ao do outro projeto, mudado apenas o módulo da API:

Isso deve ser o suficiente pra fazer o nosso serviço cinema-catalog-service funcionar. Com a criação deste segundo micro serviço, uma série de dúvidas devem lhe surgir, por exemplo, como manter controle dos múltiplos endpoints entre múltiplos microservices? Como garantir segurança de maneira uniforme entre os microservices sem ter de compartilhar dados de usuários autorizados entre todas bases de dados? E porque cinema-catalog-service não consome movies-service como imaginamos inicialmente?

Eu começo a responder estas e outras perguntas nos próximo posts, sobre API Gateways e JSON Web Token!

Curtiu o post? Então clica no banner abaixo e dá uma conferida no meu livro sobre programação web com Node.js!

O que achou desse artigo?
[Total: 2 Média: 5]