How much overhead will Mongoose add to the node-Mongodb-native driver?

How much overhead does Mongoose add to node-Mongodb's native driver? If I just wanted to have several structurally similar queries in several collections, would it be wiser to just write everything using the driver directly? For example, I would need to do something as follows (in the driver language copied from here ):

db.collection('test', function(err, collection) { collection.find({'a':1}, function(err, cursor) { *do something* } } 

Wherever I simply replace 'test' and 'a' with variables to keep the actual set and key I am looking for.

It seems to me that in this case it makes sense to just write everything using the driver directly. Will there be any reason to use Mongoose? Is the overhead so insignificant that I'm stupid when considering using the driver directly?

Best and thanks
Themselves

+4
source share
2 answers

Depends on how big your application is. If you only make a few requests, you might not want to add Mongoose to the mix, but once your application starts growing, Mongoose can help keep it more convenient. Dev time is usually more valuable than processing time.

If your application does not handle many concurrent requests, you probably won't notice the difference in performance.

+3
source

Another good thing about using Mongoose is that you clearly define your models (including default values, validation, etc.) in your application, which provide a lot of internal documentation for your application and significantly reduce the chance of inconsistencies when you have dealing with a relatively unstructured data model.

Relational databases have many functions for defining data types, default values, indexes, etc. and will cause errors if you (for example) try to use a column that does not exist.

Mongo removes a lot of overhead, but does more work, ensuring that a consistent data model is documented and maintained in the implementation code; Mongoose makes this a lot easier.

It also has many useful features to keep your models in check, including the ability to use strict schemes (the default version is v3), which means that any values ​​that you have not yet defined are not written to the database, " virtual fields ", which, for example, could combine the first and last name into a string, as if they were stored in a database (but this is not necessary) and index management. See the manual for more details.

+1
source

All Articles