Tutorial CRUD em Node.js com driver nativo do MongoDB – Parte 2

O tutorial de hoje é uma continuação de um outro tutorial aqui do blog, muito acessado aliás, onde ensino como fazer um sistema de cadastro bem simples em Node.js, usando o web framework ExpressJS e o banco de dados MongoDB. Ou seja, o famoso CRUD.

Nesta segunda parte, parto para um conceitos mais avançados em cima do mesmo projeto: paginação de resultados.

Para conseguir acompanhar todos os códigos, é importante que você tenha realizado a parte anterior ou pelo menos baixe os códigos-fonte que se encontram no formulário ao final do tutorial anterior.

Vamos lá!

Atenção, este mesmo tutorial está disponível em videoaula em meu curso de Node.js e MongoDB.

Paginação com Node.js e MongoDB

Nossa aplicação simplesmente lista todos os documentos da nossa coleção no MongoDB, sem qualquer distinção. Nas primeiras duas etapas deste tutorial vamos restringir isso, primeiramente através de uma paginação de resultados e depois através de uma busca.

Conforme trato em detalhes no artigo Tutorial MongoDB para iniciantes em NoSQL: Parte 2, fazemos paginação no MongoDB usando as funções skip e limit de maneira apropriada.

A função skip indica ao MongoDB que deve-se ignorar um número x de resultados da consulta na hora de retornar do servidor de banco. Já a função limit diz ao Mongo que ele deve retornar apenas um número limitado de documentos, independente se a busca retornaria mais elementos normalmente. Ambas funções devem ser usadas após um find, como veremos a seguir.

A lógica para criar paginação é bem simples: determine um tamanho de página, por exemplo 10 elementos, descubra o total de elementos que a consulta retornaria, por exemplo 21 elementos, e depois dividida o total pelo tamanho de página, arredondando sempre pra cima. Pronto, você tem a quantidade de páginas para aquela consulta! Neste exemplo de 21 elementos com uma paginação de tamanho 10, serão 3 páginas, sendo que as duas primeiras terão exatamente 10 elementos e a última apenas 1.

Entendeu?

Para determinar o tamanho de página ideal para seu sistema você tem de levar em consideração a performance da sua aplicação e a experiência do seu usuário. Muitas páginas com poucos elementos é fácil do banco retornar, mas ruim pro usuário ficar navegando. Poucas páginas com muitos elementos é o oposto e o segredo está no equilíbrio. Neste exemplo, ficaremos com tamanho 10 mesmo, para fins de teste.

Paginação de Resultados em Node.js

Então nosso primeiro passo será modificar uma function já existente no módulo db.js da nossa aplicação para que ela retorne os resultados de maneira paginada, como abaixo:

Note que comecei definindo uma constante com o tamanho das páginas sendo 10. Depois, adicionei um novo parâmetro na função findAll que espera a página que a aplicação deseja apresentar. Este parâmetro eu uso para calcular o skip, ou seja, quantos elementos da consulta eu devo ignorar. Se a página for a primeira, o skip será zero e serão mostrados os primeiros 10 elementos. Se a página for a segunda, o skip será 10 pela fórmula e serão mostrados os elementos das posições 11 a 20 (ordinal, ou 10 a 19 considerando um array zero-based).

Agora vamos modificar onde esta função findAll é chamada: na pasta routes, módulo index.js, que vamos modificar levemente a rota GET padrão apenas para adicionar o parâmetro página nela:

Note que coloquei o parâmetro no path como sendo opcional (?) e se ele não tiver sido passado na URL, será atribuído como um. Esse truque do || para atribuir um valor default eu ensinei no artigo 15 Dicas de JavaScript, lembra?

Certifique-se de que esta rota seja a última do arquivo index.js, logo antes do module.exports!

Como as rotas são testadas da primeira até a última para ver qual que processará a requisição deixaremos esta pro final para não interferir nas demais avaliações.

Agora execute a aplicação e teste a index passando a página na URL, como abaixo. Note que tive de adicionar muitos customers no banco de dados para podermos ter alguma paginação.

Paginação funcionando via URL
Paginação funcionando via URL

Mas obviamente não faremos nosso usuário ter de mudar parâmetros na URL para acessar as páginas, certo?

Está curtindo o post? Para uma formação ainda mais completa como programador web recomendo meu livro sobre programação web com Node.js clicando no banner abaixo!

Paginação de resultados com ExpressJs e EJS

Para que o usuário saiba quantas páginas existem e para que consiga acessar as mesmas, vamos ter de criar uma lógica para construir o HTML de paginação no frontend e uma lógica para retornar algumas informações importantes no backend.

Vamos começar pelo backend que é mais a minha praia. XD

Abra seu arquivo db.js novamente e vamos criar uma function countAll que executa o callback passado por parâmetro retornando um erro (opcional) e a quantidade de documentos na coleção customers. Note que atualizei o module.exports com a nova função e também exportando a constante com o tamanho de página.

Agora na routes/index.js, mais especificamente no nosso GET default (a última rota do arquivo), vamos ajustar as chamadas para construir o model com as informações que precisaremos no frontend EJS:

Note que tive de encadear as duas chamadas de banco uma dentro da outra, para garantir que a página somente será renderizada quando tivermos tanto os documentos da consulta quanto a quantidade total de documentos na coleção. Esse é justamente o ponto fraco do uso de callbacks, o chamado Callback Hell, mas falarei disso em outro artigo.

A cereja do bolo fica para o cálculo de quantidade de páginas que fizemos ali, dividindo o total de documentos pelo tamanho da página, usando a constante existente no módulo db.js. Ah sim, você não esqueceu de expor esta constante no module.exports, certo?

Agora que nosso model está completo, vamos mexer na index.ejs, nossa view inicial da aplicação para renderizar a quantidade total de elementos e o HTML de paginação para que o usuário possa navegar entre as páginas:

Esse código eu coloquei bem no final do arquivo EJS, onde antes ficava apenas o botão de Cadastrar novo cliente. Se você fez tudo certo até aqui, quando testar novamente você deve ver o seguinte resultado na interface da listagem:

Paginação funcionando
Paginação funcionando

Melhorando usabilidade da paginação

Para encerrar este tutorial, vamos adicionar uma perfumaria para melhorar ainda mais a usabilidade desta página: a página atual não deve ter link, apenas as demais páginas, assim, o usuário saberá em que página ele se encontra atualmente.

Vamos iniciar ajustando o model retornado no nosso index.js para informar também a página atual solicitada pelo usuário:

Note que a mudança foi bem sutil, apenas uma nova propriedade no JSON ‘pagina’.

Para fazer a lógica necessário para que o HTML ora tenha link, ora não tenha, basta adicionar um if na lógica de construção do nosso EJS usando a informação da página oriunda do model:

Ou seja, se a variável de iteração ‘i’ for diferente da página atual, escreve um link HTML na tela, caso contrário, escreve apenas o número da página. Visualmente falando temos a imagem abaixo como referência:

Indicando a página atual
Indicando a página atual

Note como ficou evidente que estamos na página 2, pois não tem link pra ela!

Outras melhorias poderiam incluir legendas quando se passa o mouse sobre as páginas, links de próxima página e página anterior, lógica para quando tivermos muitas páginas (e se tiver 100 páginas, como ficará a tela?) e até mesmo informação textual de que você está vendo os itens x a y da página z.

Mas…isso fica para você pensar meu amigo ou minha amiga! 🙂

Até o próximo post!

Gostou do tutorial? Quer aprender ainda mais sobre Node.js, ExpressJS, EJS e MongoDB comigo? Conheça meu curso de Nodejs e MongoDB clicando no banner abaixo!

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

Autenticação em Node.js com Passport – Parte 3

Este artigo é uma continuação da parte 2 do meu tutorial de autenticação em Node.js usando a biblioteca Passport. Nessa terceira parte veremos como fazer um recurso bem simples de recuperação de senha via email e de logout do usuário autenticado.

Caso você deseje ver este artigo em vídeoaula, saiba que ela está disponível em meu curso online de Node.js e MongoDB.

Vamos lá!

Criando a recuperação de senha

Agora a próxima parte é a de recuperação de senha. Lembra que deixamos um link pra isso lá na tela de login?

Vamos começar criando uma nova view, a views/forgot.ejs, com um formulário bem simples que pede a confirmação de seu email para envio de uma nova senha:

E para que essa tela seja acessível, vamos criar uma nova rota GET em routes/users.js:

Rodando sua aplicação e acessando no navegador, já deve ser possível navegar até esta página usando o link na tela de login:

Esqueceu a senha
Esqueceu a senha

Para fazer funcionar este formulário, vamos começar criando duas funções em nosso arquivo db.js: uma que busca um usuário pelo seu email e outra que muda a senha de um usuário:

A primeira função é bem simples, um findOne por email, que executa um callback após encontrar (ou não) o usuário. A segunda recebe uma senha, criptografa ela e sobrescreve o hash de senha do usuário cujo id foi passado por parâmetro. O module.exports no final do db.js também foi atualizado de acordo.

Note que não estou criando as devidas validações em nenhum formulário para os artigos não ficarem gigantescos. Nem de campos obrigatórios, nem validações de regras de negócio como não permitir usuários e emails duplicados. Tenha em mente que você deverá implementar essas questões se for usar esses códigos em produção.

Antes de sairmos fazendo a rota POST, vamos criar um arquivo utils.js na raiz do nosso projeto e colocar dentro dele uma função de geração de senha aleatória:

Esta função é bem simples e talvez você até queira usar alguma mais avançada. Aqui eu crio e retorno uma senha aleatória de 10 caracteres alfanuméricos (maiúsculas, minúsculas e números).

Agora que temos estas funções podemos criar a nossa rota POST que vai receber os dados do formulário de “esqueci minha senha”. Abra o arquivo routes/users.js e crie a nova rota:

Aqui começamos com o findUser que criamos anteriormente, que busca usuário por email. Caso não encontre, vamos jogar o usuário para a tela de login mesmo assim, embora você possa pensar em algo mais criativo para fazer.

Caso encontre, mandamos gerar uma nova senha usando a função que criei há pouco e uso o changePassword para mudar a senha do usuário que possui o email especificado (em um sistema de produção, para evitar problemas, além do email, peça alguma informação pessoal do usuário para confirmar esse processo de troca de senha). Por fim, um email é enviado com a senha que acabou de ser gerada, como na imagem abaixo.

Nova senha
Nova senha

Se você tentar se autenticar com a senha antiga, notará que ela não funciona mais, somente a nova.

É uma boa prática guardar o hash das últimas senhas do usuário e não deixar que ele use senhas antigas (mesmo senhas aleatórias podem conflitar ocasionalmente). Outra boa prática seria no primeiro login com a nova senha ele ser solicitado a cadastrar uma senha pessoal ao invés dessa aleatória. Enfim, sempre há margem para melhorar quando o assunto é segurança.

Logout

Até o momento nos preocupamos em autenticar os usuários que desejam entrar no sistema. Mas e os usuários que desejam sair? Como podemos implementar uma funcionalidade de logout na nossa aplicação?

Muito simples!

Na view index.ejs (ou onde quiser), adicione um form HTML com um botão que fará um post em uma rota logoff, como abaixo:

Agora é hora de criarmos esta rota, o que devemos fazer em routes/login.js, nosso módulo de rotas de autenticação. Adicione a nova rota abaixo:

Note que o objeto req (request) possui um método logOut(). Isso porque foi injetada esta função nele através do Passport. Se você executar esta aplicação agora, se autenticar e depois clicar no botão de logoff, não apenas irá voltar para a tela de login, mas não conseguirá acessar a área logada até que se autentique novamente.

Teste e verá que funciona perfeitamente!

Não é exatamente uma parte 4, mas este tutorial sobre JSON Web Token ajuda a preencher a lacuna de autorização (visto que até o momento vimos apenas autenticação). No caso de estar utilizando arquitetura microservices, é uma boa colocar sua autenticação vinculada a regras de autorização no seu API Gateway.

Este artigo tem uma versão em videoaula em uma das aulas do meu curso de Nodejs e MongoDB que você confere clicando no banner abaixo.

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

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 ideia 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, além deste onde falo de boas práticas em arquiteturas de microservices e como refatorar um monolito em micro serviços.

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