Parte 1: Registrar um usuário

Materiais necessários

  • Node.js
  • Express.js

Módulos de nó usados

  • Couchbase Node.js SDK/N1QL
  • analisador de corpo
  • uuid
  • node-forge

A parte mais importante da criação de uma rede social começa com os usuários. Se você tiver apenas um diretório de pessoas, estará diante da forma mais básica de uma rede social, na qual as pessoas podem aprender umas sobre as outras. Dessa forma, a coisa mais importante que um usuário precisa ser capaz de fazer é criar uma conta. Depois disso, o restante dos nossos desafios passa a ser manipular esse documento do usuário, ou pelo menos alguns aspectos dele. Antes de me aprofundar no assunto, deixe-me explicar a estrutura básica de arquivos que existe nesse aplicativo, o que será fundamental para entender como o Touchbase funciona.

Estrutura do arquivo

Presumirei que você tenha um conhecimento geral dessa estrutura de arquivos, mas, se for muito novo, consulte o tutorial de Nic Raboy sobre como criar uma API de jogo com o Node.js e o Couchbase aqui.

Em nosso app.js teremos feito grande parte da configuração necessária. Para esta postagem, pedirei que você consulte primeiro rotas/routes.js. Aqui você encontrará o '/api/registerUser' endpoint. Para quem está começando a usar o Node.js ou aplicativos baseados em API, um endpoint é simplesmente o local em que uma chamada de API REST transmitirá seus dados para o back-end. Por exemplo, se eu fizesse algum tipo de solicitação http POST no front-end para um endpoint chamado '/api/registerUser'Se eu enviar alguns dados do usuário para esse endpoint, ele executará as operações necessárias no back-end (criando um documento do usuário) antes de transmitir de volta alguma mensagem (normalmente, um objeto JSON).

API '/api/registerUser

Nesse caso, o /api/registerUser' receberá um objeto JSON que conterá o conteúdo de um formulário que o usuário preencheu para se registrar em nosso site, o Touchbase. No back-end, o Touchbase executa algumas validações básicas para garantir que as informações necessárias do usuário tenham sido inseridas para essa conta, a fim de garantir que ela possa ser usada como uma conta legítima. Primeiro, verificamos se o objeto tem atributos de nome, e-mail e senha. Todos eles também são verificados no front-end e exibem mensagens de erro; no entanto, nunca é suficiente confiar na validação do front-end. O javascript de front-end pode ser facilmente manipulado por um usuário final e pode expor falhas de segurança no aplicativo. Tendo isso em mente, a mesma validação feita no front-end é executada novamente no back-end. Certos campos são validados com expressões regulares. Por exemplo, para garantir que a senha seja forte o suficiente. Em seguida, a senha é comparada com a senha de confirmação para garantir que sejam idênticas. O e-mail também é verificado para garantir que ainda não tenha sido usado antes de usar o Usuário.advancedSearch (essa função será explicada detalhadamente em breve). Se todas essas condições forem atendidas, a função Usuário.create é executada.

Para ver o 'User.create' função, vá para models/usermodel.jsou veja o snippet abaixo. Nesse arquivo, você verá uma função chamada 'User.create'. Essa função é usada para gerar um documento JSON que descreve diferentes aspectos do usuário. Como você pode notar, alguns desses aspectos vêm diretamente da entrada do usuário, que foi passada para a função 'User.create' função como 'params'enquanto outros são gerados na criação do documento sem nenhuma entrada do usuário. Por exemplo, um UUID (identificador universalmente exclusivo) aleatório é criado como o ID do documento do usuário; saiba mais sobre UUIDs aqui. Para isso, usei o módulo de nó uuid. Esse ID de documento (UUID) deve ser uma forma exclusiva de identificar o usuário para todos os fins futuros. Como queremos ter certeza de que cada documento é totalmente exclusivo, usamos um UUID e, como queremos garantir que o documento seja o mais flexível possível, evitamos usar qualquer atributo de uso específico como ID do documento. No futuro, pesquisaremos esses usuários principalmente por atributo e raramente usaremos diretamente esses UUIDs, a menos que saibamos que estamos pesquisando um usuário específico.

Também queremos manter a hora em que o documento do usuário foi gerado e analisar os logins ao longo do tempo, por isso usamos a hora atual, que geramos usando JavaScript, e depois inserimos isso em nosso objeto aninhado 'timeTracker'. Você pode notar que essas variáveis também são divididas de forma estranha por stringAttributes, dropdownAttributes e arrayAttributes. A razão para isso se deve principalmente à forma como consultaremos esses atributos usando a linguagem de consulta N1QL do Couchbase. Isso é explicado detalhadamente em parte 0 da série do blog, mas, em essência, o motivo pelo qual ele é estruturado dessa forma é permitir que o código seja alterado muito pouco para ser reutilizado. No login, você também verá o atributo "password", que é uma versão com hash da senha que o usuário digitou. Isso é feito usando node-forge.

Função 'User.create' (Usuário.criar)

Agora usamos uma instrução de inserção N1QL para criar o documento. Em caso de erro, você verá que uma função de retorno de chamada é chamada. Você notará que há um retorno de chamada passado como parâmetro, que é a função 'function(error, result)' que você vê no rotas/routes.js arquivo. Isso é usado para evitar a necessidade de escrever repetidamente a mesma sintaxe para lidar com sucesso e erros. Se a inserção for bem-sucedida (o resultado que deve ocorrer), o resultado será passado de volta para o arquivo rotas/routes.js função para '/api/registerUser'e ele continuará a ser usado para ações futuras. Depois disso, vemos que isso é passado para 'Session.makeVerification'.

Consulta N1QL "User Insert" (inserção de usuário)

As informações que geramos em nosso último resultado foram criadas na forma de um objeto JSON que continha nosso ID de usuário e o documento do usuário, que foram gerados com o comando 'User.create' função. Para ver um exemplo do documento que seria inserido, veja parte 0. Essas informações são usadas para 'Session.makeVerification' para gerar um e-mail que é usado para verificar o endereço de e-mail do usuário. Caso contrário, o usuário não poderá acessar sua conta.

Se você quiser realizar essa etapa extra de verificação em suas contas, isso será discutido na próxima publicação, parte 2, sobre verificação de e-mail com o Couchbase, o Nodemailer e a API Sengrid.

Obrigado a todos por seu tempo e espero que tenha sido útil. Faça um comentário abaixo com suas dúvidas, comentários ou críticas.

Autor

Postado por Pranav Mayuram

Pranav Mayuram é estagiário da linguagem de consulta N1QL, Couchbase. Criou uma plataforma de rede social, Touchbase, usando o Couchbase Server, Node.js, Express e Angular.js.

Um comentário

  1. [...] até agora, a Parte 0 e a Parte 1 abrangem o modelo de dados e o documento do usuário usados no aplicativo, seguidos pela Parte 2, em que verificamos [...]

Deixar uma resposta