Isn't mongoose contradictory to nosql?

Question

I've watched many videos and tutorials on MongoDB and Mongoose, and while I think Mongoose does it's job very well, isn't it contradictory to the flexibility that a NoSql datastore offers? That being a schema-less environment.

What if I want to add a new property, or array to my document? I have to update my Mongoose schema correct? That seems counter-intuitive to the whole point of a flexible document store.

If I want my application to be more flexible, isn't Mongoose the wrong choice for my application?

Answer 1

Disclaimer: I've been using Mongoose for about 2 years in a very large enterprisey application, and have been using mongo for another year on top of that pre-mongoose.

The docs mention

Let's face it, writing MongoDB validation, casting and business logic boilerplate is a drag. That's why we wrote Mongoose.

This statement is hard to appreciate unless you've been through the pain.

Here's the dream: your application is perfect, and you store exactly what you need in exactly one collection. You can easily throw data or fetch it. It fits very well into a linux pipeline and mostly just works!

I think the reality is that we often underestimate that our data is at least slightly relational and the implications that has. Most applications will treat Mongo/NoSQL as a de-normalized datastore: a faster, simpler (to use) database that you can put full objects graphs into and read them very quickly. This is incredibly easy to use compared to SQL + an ORM. I was genuinely blown away for a while.

However, as your application develops, little things start to get more complicated...

In order to keep your embedded data from other collections in sync, you will need to handle this at the application level. That means whenever you save thing A, you may need to update things B and C somewhere else. Example: user comments: you'd want to embed basic user objects with each comment.

As time goes on, the definition of things A, B and C slowly change and evolve as your application grows.

Combine this with a loosely-typed language, and it's very easy to accidentally save an empty string instead of null, or null instead of undefined. This is the best case. Usually, these small little errors that you make are caught and cause an error. Now they will be saved into your database forever, without you knowing you even slipped up. Until your application crashes, because your data is wrong. After you a fix a few of these, you start to program very defensively. Small changes are now hard and are of higher-risk.

While you can certainly roll your own (anything), adding a small safety net between your application code and your database is always a good idea. It's nice to know that an id column always means a certain thing. Or that when something is saved, you are guaranteed to have checks X, Y and Z met.

Or when you change your username, it actually updates your comments.

The validation, query builder, pre/post save hooks, populations, and other goodies that Mongoose provides are going to save you lots of pain.

At the end of the day, you need to balance the effort you want to put in with the correctness that you are comfortable with. While I've gotten a lot of value out of plain mongo access, having mongoose has also been a nice stop-gap between Mongo and a full blown SQL/ORM combination.