• 1. TypeScript Express tutorial #1. Middleware, routing, and controllers
• 2. TypeScript Express tutorial #2. MongoDB, models and environment variables
• 3. TypeScript Express tutorial #3. Error handling and validating incoming data
• 4. TypeScript Express tutorial #4. Registering users and authenticating with JWT
• 5. TypeScript Express tutorial #5. MongoDB relationships between documents
• 6. TypeScript Express tutorial #6. Basic data processing with MongoDB aggregation
• 7. TypeScript Express tutorial #7. Relational databases with Postgres and TypeORM
• 8. TypeScript Express tutorial #8. Types of relationships with Postgres and TypeORM
• 9. TypeScript Express tutorial #9. The basics of migrations using TypeORM and Postgres
• 10. TypeScript Express tutorial #10. Testing Express applications
• 11. TypeScript Express tutorial #11. Node.js Two-Factor Authentication
• 12. TypeScript Express tutorial #12. Creating a CI/CD pipeline with Travis and Heroku
• 13. TypeScript Express tutorial #13. Using Mongoose virtuals to populate documents
• 14. TypeScript Express tutorial #14. Code optimization with Mongoose Lean Queries
• 15. TypeScript Express tutorial #15. Using PUT vs PATCH in MongoDB with Mongoose

Today we dive into MongoDB relationships between documents. To do it we use Mongoose and the populate feature. As always, the code that we cover here is available in the express-typescript repository. You’re welcome to give it a star.

MongoDB relationships between documents

The fact is that MongoDB is a NoSQL database. It means that it is non-relational, among other things. To implement a kind of relations between documents, we use references by IDs or embed documents directly.

In the previous part of the tutorial, we saved a reference to the author of the post as authorId. Let’s look into how can we handle that using features of Mongoose like the populate function. To start, we explain relationships in a traditional meaning with examples of implementing them using MongoDB and Mongoose.

One-To-One (1:1)

We can use it to describe MongoDB relationships between two entities where the element of type A may be linked to just one element of type B and vice versa. Imagine having an address schema:

In our application there is a big chance that just one user is living at a particular address, meaning a combination of a street and a city. Therefore, it makes sense to relate a specific object of address to just one user, and the user to just one address. User-address is a decent example of a One-To-One relationship, and because of that, we can use the fastest way of creating MongoDB relationships: embedding documents.

The address object got created along with the user and had been given a distinct ID. We can go to the mLab interface and look it up. There, you can see that it is embedded straight into the user document.

The One-To-One relationship in this example means that a user has just one address and this address belongs to only one user. Since this is the case, it makes sense to embed the address straight into the user document.

One-To-Many (1:N)

One-To-Many can be used to describe MongoDB relationships in which one side can have more than one relationship with the other, while the reverse relationship can only be one-sided. Let’s implement it in our application with blog posts and authors, assuming that a blog post can just have one author. It is a One-To-Many relationship because a user can be the author of many blog posts, but a blog post can only have one author. We could embed the blog post into the author document, but it would be difficult to maintain. A better idea is to refer to a user inside the post document.

The  ref: 'User' refers to the “User” document because we named it like that here:

Thanks to defining such a reference, now you can assign the user id to the author property of a post.

Populating the data with Mongoose

A great thing about it is that you can very easily replace the id with the actual data of an author with the populate function that Mongoose implements.

Small issue with that is the fact that it also returns the password hash of the user. Fortunately, the populate function accepts additional options.

The first option is to choose the properties that you want to select:

In the example above only the name of the author and his id is attached. The second way is to exclude the properties that you want to omit:

You can do the same thing in other parts of the application, for example when fetching all the posts:

An important thing to notice here is the difference between  savedPost.populate('author').execPopulate()  and  this.post.find().populate('author', '-password'). In the first example, we call populate on an instance of a Document. To execute it, we need to call execPopulate. In the second example, we use populate on an instance of a Query. To execute it, we need to call exec and it is done indirectly when the async/await mechanism executes the then function.

If you want to know more, check out Query.prototype.then and Explaining async/await. Creating dummy promises

The direction of the reference

A good question to ask is: can we attach blog post IDs in the user documents, instead of the other way around? Surely we can. When deciding the direction of the reference, we need to ask ourselves a few questions:

How many references will we have? Imagine storing logs for different machines in your server room. The Log documents would be tiny and have just a few parameters like a massage and a time. The Machine documents would have an array of either embedded logs or just ID references to the Log documents. The issue is that the maximum size of a MongoDB document is 16MB. If you have an array of all the IDs, you might eventually run out of space for the Machine document. What you can do is instead of having an array of all the logs, keep the id of a machine in the Log document. It is an example of parent-referencing.

The second question is, what queries would be the most often used in our application. In our Blog post – Author implementation it is effortless to retrieve the data of the author if you have the blog post because we store his id in the Post document. On the other hand, it is more difficult to retrieve all the posts of a single user, given his id. To do that, you need to query all of the blog posts and compare the ID of the author. Let’s implement it.

In our simple example, only the person logged in can get a list of all his posts.

Embedding vs. referencing

Having One-To-Many MongoDB relationships does not mean that using embedding instead of referencing is a bad idea. You can surely do that, for example when you have multiple addresses for a person. The main advantage of that is you don’t have to perform any additional database traversing to get the embedded details. You can’t access the details as standalone entities though, which we want to do with documents like blog posts.

In general, embedding the data works well for small subdocuments that do not change a lot. Referencing by id is slower because you need additional queries, but it works well for large subdocuments that change often and are often excluded from the result.

Many-To-Many (N:M)

Another MongoDB relationships that you may implement is Many-To-Many. It happens when two entities might have many relationships between each other. An example of that is when:

• a blog post can have multiple authors
• a user can be the author of many blog posts.

A way to implement it is to change the author property in the Post schema to the authors array.

The above is an elementary example, but there is a lot of additional things that we can implement.

Two-Way referencing

An example of an additional technique you can use in both Many-To-Many relationships, as well as with One-To-Many, is two-way referencing. It works by storing references in both entities that refer to each other. An example of it is storing references both in the Post and the User:

This implementation has some advantages. Thanks to referencing posts in the user document, we can quickly find every post that a user wrote without the need to do an additional query that traverses all the posts in your database. The downside to this is that every time you create and modify documents you need to take care of the consistency of the data and update both sides of the reference.

For the sake of simplicity, the version of the application in the express-typescript repository will have the One-To-Many relationship implemented between posts and users.

Summary

In this article, we covered how to create MongoDB relationships between documents. We also learned what their types and different implementations are and how it impacts the performance of the application in different actions such as creating, updating and finding documents. In the next part of the tutorial, we will dive deeper into aggregations, so stay tuned!