A friend who is re-learning to code after a few years away from coding (but who did a technical degree and knows Java, C++ and SQL) asked me about my thoughts on MongoDB.
They are learning the "MERN" (MongoDB, Express.js, React & NodeJS) as while following a popular Udemy course. I showed the friend Svelte as a much simpler and more intuitive alternative to React and they loved it! They re-wrote their app in Svelte and it's 60% fewer lines of code they actually understand rather than having mountains of boilerplate props, class and state code. So now they are using "MENS" (MongoDB, Express, Node.js and Svelde) stack (obviously no sexism intended!), as you will see from this issue I would actually advocate them using a "PES" (PostgreSQL, Express.js and Svelte ... with the Node.js is implied by using Express!) and who doesn't like "PES" (foot in Latin)?
History
We bought into the "NoSQL" Hype early on and build several Apps using the "MEAN" stack https://en.wikipedia.org/wiki/MEAN_(solution_stack) it was great for prototypes/MVPs!
The ability to write queries in JS meant that we could be "Full Stack JavaScript" including the DB! 😮
We used MongoDB for a couple of client projects (with full buy-in from the clients' DevOps team),
and were able to ship the App(s) to production. Using a single node was fine and performance was good for our needs but we ran into two problems which ultimately meant we stopped using MongoDB and switched back to PostgreSQL:
Lack of consistency guarantees meant that data in one instance was not reflected in others!
Lack of a schema came back to bite us in an app with 20+ devs who wanted to "move fast" (i.e. not read any of the existing code and wrote inconsistent data to the DB)
The lack of a DB schema was fine for the simple Twitter/Instagram/Telegram Hybrid for Education EdTech App that we built. If you have ever built a Twitter/Insta Clone the DB layer is quite simple, it's the UX that is the difficult part. In this particular project it was the consistency that bit us.
We were replicating data across two MongoDB instances and we would regularly get user feedback saying "my friends can't see my post but I can". This is because the friends were being served by the replica DB which did not have the content!!
The lack of a schema was more problematic in the "User Management" App we were called into help build for a different client. The client had attempted to build the App internally and had selected MongoDB to "move fast" but the devs in question had zero experience with NoSQL so had rapidly made a mess of it. We were called into help because we were one of the only agencies in London at the time that listed MongoDB experience on our website.
For instance they had fields called name, Name, firstname and firstName in the same DB!! So our first exercise was tidying up the field names using a Mongoose Schema i.e. applying a schema to a DB that was meant to be "schemaless". Then the User Management app had the concept of a "Family" i.e. a group of related users. But instead of having a relationship, they had gone with nested documents. i.e. there was a "main" user and their others were nested in document. MainUser > Spouse | Child1 | Child2 which meant that the instead of letting any of the nested people login with their own account they all had to use the password of the MainUser ... 🙄
We normalised this data and gave each person their own account (for obvious security reasons),
but now the data was starting to resemble a relational database and we were still stuck using MongoDB which has a rather "clumsy" API for querying related data.
The consistency was still not solved so the work-around was to write the data to a queue and have a worker write it to the 3 MongoDB instances. An experience I was keen to not repeat.
The final reason why I decided not use MongoDB on any new projects was their "Source Available" model https://en.wikipedia.org/wiki/Source-available_software i.e. they aren't truly open source software. You can download the binaries and you can even inspect the source.
They have a "community" edition with their own weird license: https://www.mongodb.com/community/licensing and an "enterprise" edition for people who pay them lots of money.
They develop on GitHub (kinda), but if you are not one of their existing team members your perfectly valid Pull Request will most likely be ignored: https://github.com/mongodb/mongo/pulls?page=1&q=is%3Apr+is%3Aopen
A friend who is re-learning to code after a few years away from coding (but who did a technical degree and knows
Java,C++andSQL) asked me about my thoughts onMongoDB. They are learning the "MERN" (MongoDB,Express.js,React&NodeJS) as while following a popular Udemy course. I showed the friendSvelteas a much simpler and more intuitive alternative to React and they loved it! They re-wrote their app inSvelteand it's 60% fewer lines of code they actually understand rather than having mountains of boilerplateprops,classandstatecode. So now they are using "MENS" (MongoDB,Express,Node.jsandSvelde) stack (obviously no sexism intended!), as you will see from this issue I would actually advocate them using a "PES" (PostgreSQL,Express.jsandSvelte... with theNode.jsis implied by using Express!) and who doesn't like "PES" (foot in Latin)?History
We bought into the "NoSQL" Hype early on and build several Apps using the "MEAN" stack https://en.wikipedia.org/wiki/MEAN_(solution_stack) it was great for prototypes/MVPs! The ability to write queries in JS meant that we could be "Full Stack JavaScript" including the DB! 😮
We used MongoDB for a couple of client projects (with full buy-in from the clients' DevOps team), and were able to ship the App(s) to production. Using a single node was fine and performance was good for our needs but we ran into two problems which ultimately meant we stopped using MongoDB and switched back to PostgreSQL:
The lack of a DB schema was fine for the simple Twitter/Instagram/Telegram Hybrid for Education EdTech App that we built. If you have ever built a Twitter/Insta Clone the DB layer is quite simple, it's the UX that is the difficult part. In this particular project it was the consistency that bit us. We were replicating data across two MongoDB instances and we would regularly get user feedback saying "my friends can't see my post but I can". This is because the friends were being served by the replica DB which did not have the content!!
The lack of a schema was more problematic in the "User Management" App we were called into help build for a different client. The client had attempted to build the App internally and had selected MongoDB to "move fast" but the devs in question had zero experience with NoSQL so had rapidly made a mess of it. We were called into help because we were one of the only agencies in London at the time that listed MongoDB experience on our website. For instance they had fields called
name,Name,firstnameandfirstNamein the same DB!! So our first exercise was tidying up the field names using a Mongoose Schema i.e. applying a schema to a DB that was meant to be "schemaless". Then the User Management app had the concept of a "Family" i.e. a group of related users. But instead of having a relationship, they had gone with nested documents. i.e. there was a "main" user and their others were nested in document.MainUser > Spouse | Child1 | Child2which meant that the instead of letting any of the nested people login with their own account they all had to use the password of theMainUser... 🙄 We normalised this data and gave each person their own account (for obvious security reasons), but now the data was starting to resemble a relational database and we were still stuck using MongoDB which has a rather "clumsy" API for querying related data. The consistency was still not solved so the work-around was to write the data to a queue and have a worker write it to the 3 MongoDB instances. An experience I was keen to not repeat.The final reason why I decided not use MongoDB on any new projects was their "Source Available" model https://en.wikipedia.org/wiki/Source-available_software i.e. they aren't truly open source software. You can download the binaries and you can even inspect the source. They have a "community" edition with their own weird license: https://www.mongodb.com/community/licensing and an "enterprise" edition for people who pay them lots of money. They develop on GitHub (kinda), but if you are not one of their existing team members your perfectly valid Pull Request will most likely be ignored: https://github.com/mongodb/mongo/pulls?page=1&q=is%3Apr+is%3Aopen
Conclusion
The reason I would not recommend people use MongoDB in 2020 is that they still have not resolved the data consistency issues we saw in 2013. See: https://www.infoq.com/news/2020/05/Jepsen-MongoDB-4-2-6/ The HN thread: https://news.ycombinator.com/item?id=23285249 shows how the MongoDB Developer Relations people are hostile towards people running their software. 🤦
If you need a NoSQL database to store documents with arbitrary fields, consider using CouchDB: https://couchdb.apache.org
The only
publicremnant of our time using MongoDB is https://github.com/dwyl/mongo-search and https://github.com/dwyl/meteor-search which are kept for reference purposes.