I'm trying to implement a RESTful(ish) interface to a MongoDB database in Node.js. According to the docs, the the basic idiom is something like:
var mongo = require('mongodb'),
Server = mongo.Server,
Db = mongo.Db;
var server = new Server('localhost', 27017, {auto_reconnect: true});
var db = new Db('exampleDb', server);
db.open(function(err, db) {
if(!err) {
db.collection('test', function(err, collection) {
// do stuff with collection
});
}
});
So there are three objects (server, db, and collection) involved in a basic DB access. My question is which of these can/should be loaded at startup and cached somewhere to be reused for every http request, and which must/should be recreated per request. My assumption is that it is okay for the server and db objects to be long lived, but I'm less sure about the collection object.
The collection can be long-lived, especially when the server is not operating if a big numer of collections like this. It's just memory you are using.
why shouldn't it be? the collection object itself doesn't consume much memory, it provides all functions to interact with mongodb, query, save and so on. recreating it on every request and removing it afterwards makes no sense.
Generally the callback from open should kick off the logic to start the rest of your application/server. Then you just hold on to that db reference and call db.collection per request. I usually have a service I can can call to get db ref from my REST resources to keep everything clean. Again this can vary depending on db/collection usage within the application.
Save all three things (server connection, database and collection) and kick off your app. ODMs for MongoDB like Mongoose do themselves, in case you're doubtful. You might want to use async to avoid nesting your code too deeply.
Personally, I use mongo-lite which lets me do var db = require('mongo-lite').connect('mongodb://localhost/exampleDb', ['test']);
After which I can fiddle with db.test, my collection. This saves me a lot of boilerplate.