Part 0: Creating a Data Model

Before building Touchbase, it is important to lay out the structure for how data will be stored. In the most basic form, there are really three different things we will need to store.

  1. User Document: Stores all information about a given user.
  2. Posts: All posts created by users must be stored with information needed for display.
  3. Images: All user profile images must be stored as binary data (base64 in this case).



First, we'll start with the user document. This document is simply stored under a UUID (Universally Unique Identifier). The reason for this is that the document ID shouldn't tell us anything about the user; all of that should come from the document's contents. For example, let's say we stored each of the user documents using the user's email address as the document ID. If a user wanted to change their email, it would be a huge ordeal, because you would now need to store their current document, then store it again under a new document ID and delete the old document. By implementing a UUID, we can find the user and change their 'email' attribute in their document using a N1QL UPDATE statement. This explains why something independent of the document's contents should be used. We also want to make sure that none of the document IDs are going to be the same, so this will algorithmically ensure that duplicate document IDs are virtually impossible. Below, you will see the 'uuid' attribute, which is used as the document ID.

Example User Document

(note, some fields have been hidden!)

This user document is linked to the rest of the documents in different ways, but the most important thing is to keep all the information that the user inputs with registration. These can be broken down into three different kinds of information, which would be: 'array attributes', 'string attributes', and 'drop down attributes'. These are typically the three ways in which a user would input information, and the application would change how they are treated accordingly. The attributes can be changed accordingly in the config.json file, so that the user is asked for different information. This may not be considered the most intuitive approach to a data model, but it streamlines the application development significantly. The config.json document can be seen below, showing how the data could be customized by a developer (user will be asked for different information), but still be treated the same by the application. The customization of these attributes would occur in the 'dataModel' object.




Next, we'll have to store posts. These are simple JSON documents as well, and they will keep information we need about each post. These are stored as UUIDs as well, with '_pub_' appended.

Example Post Document

Each post has three major parts: title, link and blurb. This contains almost everything that is necessary in a post, but there are other simple things we will store on the back-end, which the user will not directly input.

First off, we will use the user's ID and store it with the post. We will also store the time at which the post is made. There is also a 'pubType' attribute, which is the type of publication that was made, and this is taken from where the post was made on the front-end.

For example, if we made the post in the 'Github Projects' section, the 'pubType' that was stored would be 'Github Projects'. There would also be an 'imagePath' associated with this 'pubType' in the config.json document, which would get the corresponding image for this 'pubType' from the icons folder.

Finally, when we are pulling the post documents, we will use a function to manipulate these documents and send them to the front-end as we see fit. In the current implementation, a N1QL query is executed to find each document that is of the 'pubType' that the user's screen is on (ex. if user is on 'Github Projects', only docs with a 'pubType' of 'Github Project' will be pulled). Then the documents will be ordered by the time they were posted, so that the newest ones are first. You may have also noticed that we only stored the 'authorID', not the author's name. The function that pulls the posts will also do a lookup for each author's name according to the 'authorID', in case the author changes their name on the network. There will be an in-depth look at the post storage and retrieval later in the blog series.



Finally, we'll have to store images. Currently this is done using Multer, a piece of Node.js Middleware. This will also be explained in more detail later in the blog series. One important feature of image storage is that we will need to associate this image with the user document for the same user. The way this is currently done is through the picture's document ID, where the document ID is stored with the same ID as the user document with '_picMulterNode' appended to the ID.

Picture Document ID



Future Blogs : This blog series will be focused around the back-end aspect of this application, especially since it follows REST principles. The explanations will focus around Node.js code using the Express framework, however, some HTML and Angular.js code will be shown when necessary to the REST API implementation. To see the full code, with front-end included, go to For the front-end, this makes use of Angular.js, HTML5, Angular UI Router, Angular Material Design, and more. All of the Angular.js code can be seen in TouchbaseModular/public/js. HTML can be seen in TouchbaseModular/public within index.html (uses signUp.js) and nav.html (uses touchbase.js). All of the Angular UI Router HTML partials can be seen in TouchbaseModular/public/html. More in-depth design documentation can also be seen in the Documentation folder.

This completes our data model blog, and I hope it was useful to you all. If you have any questions, concerns or feedback, please drop a comment below.


Posted by Pranav Mayuram

Pranav Mayuram is a N1QL Query language intern, Couchbase. Built a social network platform, Touchbase, using Couchbase Server, Node.js, Express & Angular.js.

Leave a reply