The logic of working with MongoDB in the server on Node.JS?

Question

NoSQL

The question is rather banal, but it seems that it is not considered in detail anywhere: how to properly organize work with the database, given the asynchronous nature of node.js?
That is, when to connect and close the connection to the database - with each request or once when starting / stopping the application?
Should we cache collection interface objects and reusable cursors?
And if you keep the connection open, then how to handle possible breaks?
If you know a good example of an application in which all this is correctly implemented, share a link to the source code. Otherwise, all the examples in the documentation are reduced to a primitive chain db.open() -> db.collection() -> collection.crud() -> db.close()

Answer 1

As far as I understand, the adapter takes care of this work. Those. in the application you don’t need to worry about this, you create a connection once and use it. Everything else happens behind the scenes. I think you can read more about this in the documentation for the mongodb adapter.

Answer 2

I use mongoosejs, an example of a good architecture for it is github.com/madhums/node-express-mongoose-demo
In mongoose, a connection pool is automatically created (by default, 5 pieces), there is an option - auto-reconnect.
Schmatically it works like this: when you start the application, you make a connection with the options you need - and that's all, in all other modules, just require ('mongoose') and do whatever you want with the base (since the module is pulled up cached with an established connection)

Answer 3

When you initialize your application, connect to the database once using MongoClient . The MongoClient object creates a pool of connections to the database, and will automatically restore the connection in case of a break. Also, when initializing, I recommend getting all the necessary collections for further work with them, because in addition to the overhead for creating JS objects in strict mode, getting a collection causes a check for the existence of the collection in the database. In this case, the cached collection objects will take advantage of the MongoClient object described above.- connection pooling and reconnection in case of a break. There is no need to close connections on your own, the connection has no context and locks. That is, the logic is something like this (very conditionally, without taking into account the application architecture):

// init db:
MongoClient.connect('mongodb://localhost:27017/dbName', function(err, db){
    cached.db = db;
    // init collection:
    db.collection('collName', { strict: true }, function(err, coll){
        cached.coll = coll;
    });
});
// usage in request:
cached.coll.insert(...);

Answer 4

When using a single database connection, there is a serious risk of overloading the base socket so much that it will become the bottleneck of the entire project. This is a rather sneaky nuance that is not noticeable during the testing and commissioning phase (like the race problem in mongo, but that's a separate conversation). I had this, though not on mongo, but on pg, but the essence of this does not change: while the base socket is busy pumping large amounts of data on specific pages, the site will be blocked. But opening a connection to the database for each request is also not the best idea, since opening, configuring and maintaining the connection requires a disproportionate amount of resources (including on the database server). Therefore, there must be a database connection pool. Mysql and pg drivers have such a pool, I'm not sure about mongodb,

Answer 5

Different drivers solve this problem in different ways, for example, native like this
github.com/mongodb/node-mongodb-native/blob/master/docs/articles/MongoClient.md
You can see what is actually happening in the source code.
But in the general case, it will be correct: open a connection -> write / read -> close
a connection against the background of the general cycle "received-recorded" was simply indecently large.
But in this case, it is necessary to provide for a reset at the first significant downtime.
Monga is somehow not good with long connections, well, at least it was like that before ...

Answer 6

I did not use the node, but in the same twisted wrote a connection pool, which itself takes care of everything.