Everyone uses mongoose!
I do not like mongoose, all the abstractions that it implements have not been very useful when making complex transactions that require more of one query to work. Also, i end up learning "mongoose" instead of mongodb.
However, I recognize the importance of the scheme, since it "facilitates" the reading of the code for other programmers of the team.
Normally (talking about an api), the first thing I do with the incoming data is to check and validate them so that the controllers work only with "clean" data and do not have to work in vain if any incoming data is incorrect.
Due to the previous thing, to implement schemes in the model becomes unnecessary, since the data are validated. I like this, but there is still a problem, the programmers must analyze the validators, to understand what type of data they are handling.
The easiest solution would be to create the scheme, even though the data is already validated, but this would lead to repeating a lot of code throughout the application.
Do you think that the schemes are overvalued?
Am I missing something?
Have you experienced something similar?
How have they solved it?
Any useful advice for a newbie?
I know it might seem silly, but lately I'm "a little bit" more attentive to architecture, and I see that working without schemes and models goes against to the MVC.
Top comments (40)
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.
Thanks for your words!
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.
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 😉
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!
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.
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
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)
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?
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:
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.
That's!
That's what I think about validation, and that's the main reason why I migrated to the native controller.
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:
Using pure Mongo:
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.
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.
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.
MongoDB had native schema validation since 3.2 (2015) but who cares - everybody promotes Mongoose in their courses.
I see, thanks for sharing your comments!
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?
Forget installing it on Windows and configure it on mlab.com.
mlab is really slick.
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 ;)
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
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/
I have been working my way through YouTube conferences, docs and examples. Cannot wait for comprehension to give way to practicality
GraphQL isn't a database as far as I remember. Just an abstraction layer on top of a database. No?
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.
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.
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.
Very true, sometimes we forget that productivity matters. With mongoose we are definitely more productive.
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
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.
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!