Exploring Couchbase and N1QL through Touchbase using Node.js and Angular.js – Part 1: Creating a User Document

Part 1: Register a User

Necessary Materials

• Node.js
• Express.js

Node Modules used

• Couchbase Node.js SDK/N1QL
• body-parser
• uuid
• node-forge

The most important part of building a social network begins with the users. If you just have a directory of people, you are looking at the most basic form of a social network, where people can learn about each other. In this way, the most critical thing a user needs to be able to do is create an account. After this point, the rest of our challenges become manipulating this user document, or at least some aspects of it. Before I go further into depth about this, let me explain the basic file structure that exists in this application, which will be critical in understanding how Touchbase operates.

File Structure

I will assume a general proficiency with this file structure, but if you are very new to it, please refer to Nic Raboy’s tutorial on creating a game API with Node.js and Couchbase here.

In our app.js file, we will have done much of the necessary setup. For this post, I will ask you to first refer to routes/routes.js. Here one will find the ‘/api/registerUser’ endpoint. For anyone very new to Node.js or API-based applications, an endpoint is simply where a REST API call will transmit its data to the back-end. For example, if I made some sort of http POST request on the front-end to an endpoint called ‘/api/registerUser’, I could send some user data to this endpoint, and it will perform the necessary operations on the back-end (creating a user document) before transmitting back some message (typically, a JSON object).

‘/api/registerUser’ API

In this case, the /api/registerUser’ endpoint will receive a JSON object which will contain the contents of a form that the user had filled to register for our site, Touchbase. On the back-end Touchbase performs some basic validation to make sure that necessary user information has been input for this account to make sure it can be used as a legitimate account. We first check that the object has name, email, and password attribute. These are all checked on the front-end as well, and display error messages, however, it is never enough to trust the front-end validation. Front-end javascript can be easily manipulated by an end-user, and could expose security holes in the application. Keeping this in mind, the same validation done on the front-end is performed again on the back-end. Certain fields are validated with regular expressions. For example, to make sure that the password is strong enough. Then the password is checked against the confirmation password to make sure they are identical. The email is also checked to make sure that it has not already been put in use before using User.advancedSearch (this function will be explained at length soon). If all these conditions are met, the User.create function is executed.

To see the ‘User.create’ function, go to models/usermodel.js, or look at te snippet below. In this file you will see a function called ‘User.create’. This function is used to generate a JSON document that outlines different aspects of the user. As you may notice, some of these aspects come directly from the user input, which was passed to the ‘User.create’ function as ‘params’, while others are generated upon the document’s creation without any input from the user. For example, a random UUID (universally unique identifier) is created as the user’s document ID; learn more about UUIDs here. For this, I used the uuid node module. This document ID (UUID) should be a unique way to identify the user for all future purposes. Because we want to make sure that each document is completely unique, we use a UUID, and because we want to ensure that the document can be as flexible as possible, we avoid using any particular use attribute as the document ID. In the future, we will primarily search these users by attribute, and we will rarely ever be directly using these UUIDs, unless it is in a case that we know we are searching for one specific user.

We also want to maintain the time the user document was generated, and look at the logins over time, so we use the current time, which we generate using JavaScript, and then insert these into our ‘timeTracker’ nested object. You may notice that these variables are also split up oddly by stringAttributes, dropdownAttributes and arrayAttributes. The reason for this, is mainly because of how we will query these attributes using Couchbase’s N1QL query language. This is explained in depth in part 0 of the blog series, but in essence, the reason it is structured this way is to allow for the code to be changed very little to repurpose it. Within login, you will also see the attribute ‘ password’ which is a hashed version of the password that the user entered. This is done using node-forge.

‘User.create’ function

We now use a N1QL insert statement to create the document. Upon error, you will see that a callback function is called. You will notice, that there is a callback passed in as a parameter, which is the ‘function(error, result)’ which you see in the routes/routes.js file. This is used to avoid having to repeatedly write the same syntax to handle success and errors. If the insert is successful (the result that should occur), then the result will be passed back to the routes/routes.js function for ‘/api/registerUser’, and it will continue to be used for further action. After this we see that this is passed to ‘Session.makeVerification’.

N1QL ‘User Insert’ Query

The information we generated in our last result was created in the form of a JSON object that contained our userID, and the user document, which were generated with the ‘User.create’ function. To see an example of the document that would be entered, look at part 0. This information is used for ‘Session.makeVerification’ to generate an email which is used to verify the user’s email address. If not, they won’t be able to access their account.

If you care to take this extra step of verification in your accounts, that will be discussed in the next post, part 2,about email verification with Couchbase, Nodemailer and the Sengrid API.

Thank you all for your time, and I hope this was useful. Please drop a comment below with any questions, feedback, or criticism.