DEV Community

Cover image for Mongodb-native over mongoose?

Mongodb-native over mongoose?

Jacob Samuel G. on March 03, 2018

Everyone uses mongoose! I do not like mongoose, all the abstractions that it implements have not been very useful when making complex transactions ...
Collapse
 
ben profile image
Ben Halpern

I think it definitely varies from person to person which abstraction layer they want to insert at. Mongoose certainly is an abstraction and is probably not for everyone or every use case.

Collapse
 
tojacob profile image
Jacob Samuel G.

Thanks for your words!

Collapse
 
sergiodxa profile image
Sergio Daniel Xalambrí • Edited

Being MongoDB a database without real schemas and structures of the data you save in each document of each collection I always felt the schemas of mongoose is trying to use MongoDB as a SQL db, and if you are going to do that just use PostgreSQL, MySQL, etc.

That said, mongoose is far better than any ORM for PostgreSQL and MySQL on the Node.js world IMO.

goes against to the MVC

You may not need to use MVC if you don't like to follow it, it's not a rule you need to always follow 😉

Collapse
 
tojacob profile image
Jacob Samuel G.

Hello! The world is small, i know you from Platzi.
Your opinion gives me some peace of mind. I think that the mvc "sometimes" feels forced in javascript.
Cheers!

Collapse
 
yentsun profile image
Max Korinets

I actually stopped using MVC (also ORMs, also OOP) after a couple of years developing on Node.js.

My life got much easier since then and I never looked back.

Thread Thread
 
rpajf profile image
Raphael Portela

What do you use , instead of MVC? i dont use OOP in front end, but in the backend i only know how to develop using classes

Thread Thread
 
yentsun profile image
Max Korinets • Edited

I was using Seneca (microservice framework) and it changed my mindset in the first place. Your microservice has endpoints (HTTP, AMQP, MQTT, even TCP, whatever) and these endpoints handle whatever comes to them. Period. If you need to abstract logic (i. e. for example not call DB directly from endpoint handler) - you abstract it with functions. I also learned that HTTP(REST) is not the only protocol out there but most MVC frameworks consider it such. In fact its rather primitive, but probably most commonly used one, okay.

Later I started designing non-micro services (monoliths) as if they were Seneca's microservices. Flat structure, no hierarchy, no classes - just endpoint handlers or 'C' in MVC and some internal services (you probably heard of services in MVC too, when Model methods are not enough - btw thats when I started to doubt MVC).

And later I realized that our backends in general are just I/O brokers / mediums. They listen to endpoints, handle the calls by just calling other internal / external services (DB, Redis, SendGrid, Stripe) and respond. Yes - call to a DB is no different from a call to Sendgrid or a call to any other API. In MVC you think database and the Model is something special.

As I remember MVC comes from Java where you can't do anything without a class or interface but for some reason it had spread to other languages.

Here is an example I only have in the open: gitlab.com/venture-api/gate/tree/d....

(Maybe I need to write an article on this to get my thoughts and experience organized)

Thread Thread
 
rpajf profile image
Raphael Portela

Thank you so much for such a complete and elucidating answer. I started programming in june of 2019, im focused on node, ReactJS(using hooks) and React Native, I use sequelize in the backend, and yes, on MVC when your controller is getting too big, the creation of aditional services is required. I started learning mongoose this week and i saw that the comands were not so different from the ones on MongoDB itself, unlike sequelize(the most known ORM), and then i landed on this page. I saw your code on gitlab, its very different from what im used to do, i will gitclone and explore this example, but what do you suggest me doing? stick to mvc a bit? learn mongo, learn pure SQL, maybe flutter in the end of 2020?

Thread Thread
 
yentsun profile image
Max Korinets • Edited

Surprisingly I'm doing some frontends right now and use React Hooks too :) I'd say Hooks is a beautiful piece of technology (rarely seen nowadays) and I'm really excited about it!

My advice will probably be:

  • if you joined an existing project - you won't have the luxury to get away from MVC in near future as employers consider it a standard and you will have to do it
  • don't forget that there is something else, try non-MVC on a pet project
  • dig CQRS + Event Sourcing (until you fully understand what it is, seriously) - this will be a revelation, also altering your mindset a bit
  • after digesting CQRS/ES, you will likely discover that MongoDB (in its initial state, no schemas) is an ideal read-only 'projection' storage rather than general data storage. It looks like being under pressure by the industry, so it tries to be a general data storage. Emerging of Mongoose is probably the result of this pressure too :)
  • Postgres (or other flavours of SQL-based storages) on the other hand, is a better general data storage - schematize your data to your heart with the variety of types
  • haven't tried Flutter but I have strong confidence in React Team, I'd probably prefer their stuff. I haven't touched mobile development yet though :)
Collapse
 
kevnz profile image
Kevin Isom

I've used Mongo in my node apps for at least 7 years, I've used Mongoose once in that time, and hated it (was chosen before I got onto the project) Otherwise I've either used mongojs or mongodb, much nicer experience. If you are using a schema-less db, why on earth do you want to bring in a schema? Maybe validation? But really, your validation should probably be somewhere before hitting the db/model, at either the api entry point or before it ever leaves the browser. So validation should be sharable between the client and server, not at the db level.

Collapse
 
tojacob profile image
Jacob Samuel G. • Edited

That's!
That's what I think about validation, and that's the main reason why I migrated to the native controller.

Collapse
 
helenasometimes profile image
Nienke • Edited

So my first reaction to your question was "huh, why would you not want to use Mongoose?" I am using Mongoose because it was recommended to me, and I never really looked into using MongoDB without it.

But then I looked at the MongoDB docs, and you are on to something! Compare the queries below:

Using Mongoose:

Book.find({ 'released_in_year': 2017 }, 'title author')
Enter fullscreen mode Exit fullscreen mode

Using pure Mongo:

db.book.find({released_in_year:{'2017'}}, {title: true, author: true})
Enter fullscreen mode Exit fullscreen mode

I'd say they're both pretty readable. What I think is the answer to "should I use Mongoose or not" really depends on the app you're building. For simpler apps you don't need the extra abstraction layer that Mongoose adds. For more complex apps with complicated querying, using Mongoose probably makes your life a bit easier.

Collapse
 
tojacob profile image
Jacob Samuel G.

It's true, it depends on the application.

Personally I have decided not to use mongoose in projects where 80% of its extra features will not be used (schema, virtuals, pupulate, hooks, etc.).

And although it is not "so" important, the native driver is faster! The only thing is that we must manually configure the connection pool, although it is not difficult.

Collapse
 
perrydbucs profile image
Perry Donham

I promote Mongoose in my courses as a design tool. Abstraction is often used as a contract, and with a Mongoose schema I can create and enforce the contract for the interface into the database. The schema also helps me think about the structure of the data and its relationships.

If the app had a requirement for storing arbitrary objects I'd probably just use mongoDB without the Mongoose abstraction, but in my experience that sort of requirement is pretty rare.

Collapse
 
yentsun profile image
Max Korinets

MongoDB had native schema validation since 3.2 (2015) but who cares - everybody promotes Mongoose in their courses.

Collapse
 
tojacob profile image
Jacob Samuel G.

I see, thanks for sharing your comments!

Collapse
 
c0d3rm0nk3y profile image
Peter

Mongodb was the first serious database I learned when I fell in love with web dev and node.

Unfortunately I am having the hardest time installing it on a Windows 7 machine I had to factory reset. Has anyone had experience with graphql? Is it better more more usable than Mongo?

Collapse
 
theoutlander profile image
Nick Karnik

Forget installing it on Windows and configure it on mlab.com.

Collapse
 
ben profile image
Ben Halpern

mlab is really slick.

Collapse
 
lennaht profile image
Lennart

As far as I know graphQL is just a query language and not a database system. If you want to work with it, you still have to install a database. Someone correct me if I'm wrong ;)

Collapse
 
c0d3rm0nk3y profile image
Peter

My apologies I'm not looking for something that I don't need you install.

I was just wondering if anyone had experience with graphql and mongoose and Clips Blaine some differences.

Sorry about that

Thread Thread
 
tojacob profile image
Jacob Samuel G. • Edited

Hi Peter. As they mentioned before, graphql does not store data (it is not a database). It is a query language for APIS. In other words, it allows you to communicate with an api through queries like "SQL", that's all. It is more like a tool, that allows to work with an architecture different from the traditional REST APIs that work through endpoints and HTTP methods. I highly recommend reading the documentation, it is vastly fresh! :) graphql.org/learn/

Thread Thread
 
c0d3rm0nk3y profile image
Peter

I have been working my way through YouTube conferences, docs and examples. Cannot wait for comprehension to give way to practicality

Collapse
 
buinauskas profile image
Evaldas Buinauskas

GraphQL isn't a database as far as I remember. Just an abstraction layer on top of a database. No?

Collapse
 
carljdp profile image
Carl J du Preez

I'm glad to see some other people also questioning, and not just blindly accepting something which everything else was doing..

I suppose this is definitely one of those topics which very much depends on you personality type and view of the world: I tend to like un-opinionated frameworks - I like the freedom to find solutions on my own terms.

Schemas/ORMs (like via mongoose) make me feel like i'm being forced into a box.

Collapse
 
crashcartcoding profile image
David

Panacea - There is none in coding.

Today you might not want or need mongoose, other times you might.

It’s a tool, just because you decided it isn’t the tool for your current job doesn’t mean it doesn’t belong in your toolbox.

Collapse
 
iiddoo profile image
Ido Lev • Edited

Great discussion!
I am still using MongoDB naive driver for my applications, my seriously considering moving to mongoose.
The main reason is that security (JWT e.g.), modeling and verification (ObjectID e.g.) would be much easier and cleaner with mongoose.
Using mongoose bulit-in library, would allow you to reduce code from your project and let you focus on your core application.

Collapse
 
tojacob profile image
Jacob Samuel G.

Very true, sometimes we forget that productivity matters. With mongoose we are definitely more productive.

Collapse
 
jenc profile image
Jen Chan

the first db I learned was mongo and now I’m looking at sql. I wonder what they’re good for....
This is coming from someone who wants to make tiny web apps that take open data and with hundreds of users in mind only

Collapse
 
tojacob profile image
Jacob Samuel G.

If you know well the concurrence of what you are going to build, it is a great advantage.

In my opinion, if your data manages "many to many" relationships you should use relational databases, even for "one to many". You can make complex relationships in mongodb, but you should make several calls to the database to populate the references, which translates into more code lines and more checks. If that does not concern you, then go for mongodb.
As an extra note, with mongoose you do not have to worry about references, since he handles them for you. It's one of his advantages!
I do not like mongoose, but I'm aware that it's very useful.

Mongodb, or any other noSQL, stands out in applications that handle very specific relationships.
Also, it is very useful for applications in constant change and evolution, it works great in methodologies that use the "minimum viable product", since it allows you to modify the flow of data easily, thanks to its flexible scheme.
Another thing that stands out from mongo is its native ability to scale horizontally.

All this is my opinion and experience. I currently use mongo because it works well with nodejs and it was the first thing I learned. However, I want to learn postgreSQL in the future, since a query language has its own benefits.

Collapse
 
jenc profile image
Jen Chan

thanks for sharing your experience. I’ve used mongoose once (forgot about it) and mongo native driver since then. Ive been doing Postgres queries at work and I find that it’s much more semantic than mongo .find() etc but I can see how relationships between tables are very structured to begin with. I’ve yet to see how creating and updating a sql db differs; will have to report back on that one!

Collapse
 
sunilksamanta profile image
Sunil Kumar Samanta

Isn't Mongoose like spoon feeding? I had a really bad experience with mongoose for a large data set.
If you're going large you should go with the Father.
@Jacob you spoke my words. Thanks for this post

Collapse
 
fqmonte profile image
Fabiano Q. Monte

I am using native mongodb. Yeah, I'm doing a crawler. So I need to record data directly in the database without needing schemas. The problem is that the MongoDB drive documentation for Node is out of date and for more elaborate things it is quite complicated to find documentation. Everyone uses mongoose. And think, in the case of service communication. OK! Use. But, in the case of reading a url, extraction, insertion in the database. Then if you fall into an error you end up not finding the solution easily. For outdated documentation and growth of mongoose. If anyone knows of any solution to work with great load with NodeJS and native MongoDB. I'm grateful.

Collapse
 
maxyou profile image
Hongyu You

At the beginning I want to save time, so I learned mongoose. When I need to use aggregation/lookup or similar, I don't know how to it in mongoose or feel to be restricted.

Now I back to mongodb native. I get all, especially, freedom.

Collapse
 
kpgit1993 profile image
Kaustab

Why I should use mongoose when I am looking desperately to move to MongoDB in order to get rid of all kind of nonsense schemas.... only usefullness I find is that it can provide an abstraction layer to work with OOP applications in format of model...

BUT basically I will choose native Mongo to avoid break for schema... please coreect if there is any other usefulness Mongo can provide....

Collapse
 
cpachmayr profile image
Coby Pachmayr

I realize this is an old thread, but thought I'd reply here for others who come along like I did. :-)

Although I'm new to MongoDB and GraphQL, I think that is the best reason for why one would want to have (or need) a Schema with a something like MongoDB.

I'm still working through whether to use mongodb-native or mongoose ... but thought I'd share that as I've been learning GraphQL, making sure that I have consistency between my schemas and resolvers has been helpful.

Collapse
 
mrm8488 profile image
Manuel Romero

You could create a joi schema as MW to validate your data and keep a reference of what kind of data you are saving.

Collapse
 
tojacob profile image
Jacob Samuel G.

In fact, I use joi, it is very good and allows for deeper validations, even sanitation and escaping.

Collapse
 
theoutlander profile image
Nick Karnik

I am a huge proponent of Mongoose. What are the scenarios where Mongoose doesn't work for you?

Collapse
 
tojacob profile image
Jacob Samuel G. • Edited

Hello Nick! I have been reading more about mongoose, I know it is quite useful and has everything covered. But that's what I do not like.

Sometimes I prefer to use other libraries (or create them) to perform specific jobs, such as validation or sanitization, for example.
In the end, term using few features of mongoose.

I guess it's a personal thing, but I want to know the opinion of other developers about this. I see that there are very few using the native driver, nor do I plan to go against the current :)