DEV Community

Cover image for It’s time to get over mongoose for your Node application

It’s time to get over mongoose for your Node application

Aniket Rathi
Working on backend engineering and will be trying to share some glimpses of my learning every week.
Updated on ・2 min read

MongoDB is an easy-to-use and open-source database system designed to store data in document format. This is quite different than the traditional SQL databases which store data in the form of tables. Hence this makes MongoDB fall in the NoSQL category. These documents in MongoDB consist of a series of key/value pairs (similar to a hashmap in java or dictionary in python). A table of SQL is equivalent to a collection in MongoDB whereas a row is equivalent to a document. Each collection does not have a fixed definition of a document. Since the data to be stored is not structural, this makes MongoDB quite flexible for which we can see that the firms around the globe have been migrating their databases to MongoDB.
With this flexibility comes the problem of unstructured data. Developers familiar with SQL databases find it difficult to switch to such unstructured storage systems. This is where the mongoose comes into the picture. It is a powerful MongoDB ODM(Object Database Modelling). This helps in defining the structure of documents and connecting to MongoDB. This facilitates the developers who worked with SQL databases to migrate to the Mongo community. It also provides abstraction thus making object definitions more readable. So far so good.

Where’s the problem?

When building small applications, one can surely choose mongoose. But when it comes to large-scale applications where a user-data object is not restricted to just his address, email, and username, defining a structure becomes a tedious task. Also, such a type of data modeling will not be recommended by your data analysts.
Mongoose acts more like middleware in your node application that can validate the incoming data and restrict it for bad inputs. But do you really need an extra NPM package to do that for you? This can easily be handled for essential input fields by your services before forwarding it to your DB service. With time the structure of the document will change drastically and making a schema out of it will be a very complicated task. When dealing with information coming from packets, this will differ from one packet to another. Any packet containing important information won’t enter your database if it does not satisfy the mongoose schema hence deviating from a real-world scenario.

What should be done?

Well, if you are into NodeJS, you might be familiar with creating your own middlewares. You can use MongoDB native driver to connect to the database and write your middleware over it. This middleware can authenticate the required fields for you and pass your document in the next() method. This ensures that you don't create inappropriate documents and does not restrict your incoming data to a pre-defined schema. Your system should be able to welcome data of any shape allowing analysts to look out for irregularities among fields too instead of a restricted schema. Also, you might like to skip an extra package when your package.json increases with time.

If you want to use a schema-less database, why on earth would you choose a schema just to ensure input validations?

Discussion (0)