Recently, as I set out to start a new project, I was faced with the daunting task of determining my application’s tech stack. Up until this point I had worked primarily with PostgreSQL aka Postgres. I was familiar with MongoDB but had never implemented it within a project. At the strong urging of a good friend, “it’s so easy!”, I decided to jump in and learn a new database program.
The process of finding great resources, downloading the right tools, and getting started with a new technology is an experience many developers know well. While MongoDB did ultimately prove to be very intuitive, many questions came up along the way and I believe that in sharing my experience I may help others to bypass some of the blockers I encountered. In part one, I will walk you through getting set up, connecting the database to your server, and creating a schema.
Relational databases, think SQL, store data in columns and rows as tables. Each row being an instance of that data model. In contrast, MongoDB is a non-relational database and each instance of the data model is stored in documents as a collection. The first aha moment for me was in learning that documents within the same collection do not have to be the same size, they scale depending on the use case. A SQL table is much more rigid with every instance of the table containing the exact same fields (“properties” in MongoDB), resulting in a bulkier database and possibly many empty placeholders. When working with simpler sets of data that include few or no associations, MongoDB makes great sense.
Getting Set Up
First thing first, install MongoDB Community Edition found here. I already had Homebrew installed locally, if you do not go ahead and follow the Homebrew installation instructions. Otherwise, run the commands for brew tap and brew install displayed in the documentation.
Great! Now enter the command to run MongoDB Community Edition, and connect a shell by typing “mongo” and pressing enter.
Now you can use MongoDB on your machine to create databases, collections and documents. You can enter all of the necessary commands through your terminal, but I prefer downloading, installing and using the Mongo GUI Compass, which you can access here.
Mongoose is an Object Data Modeling library for MongoDB. Just as Sequelize is to SQL, Mongoose is to MongoDB. Mongoose provides tools for communicating with MongoDB. When setting up your server, you will want to install mongoose and utilize the connect function to connect to your database every time you run your server.
Mongoose also provides methods for creating database schemas and built in validators. Think of Sequelize models, because the structure is very similar though the implementation can be quite different. Exploring a simple use case of user account data, in your models file create a user schema with all of the necessary properties. This schema will then become a model through the mongoose.model method, this method takes in the model name and the schema. Mongoose will automatically add an id property to each schema as “_id”. Now export the model at the bottom of your file.
Making the use case more complex, let us consider that perhaps your user has children and you need to store their data with the user’s profile data. I arrived at two possible routes, create a separate schema and nest it within the user document, or nest the child document itself within the user document. I found that the second route made more sense to me and seemed like a simpler approach. Go back into the models file, and refactor the schema to incorporate an array of child documents. Each child in the array is their own sub-document and will have their own id assigned as “_id”.
I really enjoyed learning MongoDB with Mongoose. This demo only skims the surface of getting started and implementing an organized data flow. In part two I will cover building routes to access the data, making database queries, and exploring more complicated associations. I have not yet encountered a use case where the simplicity of MongoDB was outweighed by the need for the foreign-keys and through-tables of SQL. I would also like to explore best practices for refactoring a large data set when one property of the model document must be changed for all instances. I hope this was helpful!
Below I have included some more thorough resources that I enjoyed.