We have an express app, and it's using a mongo database for various
configuration details. The app itself can have any number of plugins, and
in some cases a plugin needs its configuration immediately upon load.
Plugins need to be loaded pretty early on so that they can theoretically
hook into and/or override core functionality.
In our current app, the database is loaded inside a "db manager" module.
When that module is loaded, it immediately creates a new connection to a
mongo database. After that, plugins are loaded and initialized. Then our
app's main code is run: setting up handlers for various routes, setting up
nowjs handlers, etc.
Previously, this worked fine. Now that we're trying to set up plugins from
the persistent database, though, it's all broken. Many of you probably
already realize what's going on: the db open() method is, of course,
asynchronous. This means the query to pull plugin configuration is relying
on a connection that hasn't yet been established.
I'm not sure why it silently fails when I do a find() call - I would have
expected it to tell me the DB isn't ready or something - but that is beside
the point. We need to figure out a better approach so that plugins can get
their DB configuration properly.
So I see a few approaches and I'm wondering if we're going about this all
wrong.
*One*: in Rails and other frameworks I've used, there's generally a single
DB connection that all queries go through. I'm used to having a way to
just grab the top-level DB object rather than having to open and close a DB
connection every time I make a query. But in node, making this kind of
thing happen (and making sure the DB exists prior to the app running) feels
really awkward to me. I end up having to do something like this:
db.open(..., function(err, obj)) {
# All app code goes here
}
This just feels wrong to me, having all the app's logic essentially in a
function, but maybe that's a typical best practice, I have no idea.
*Two*: another option would be to just open and close DB connections
everywhere we need them, so that we don't have this concept of an app-wide
DB instance. To me, this feels backwards for a long-running app, but again
I really don't know what is considered a best practice for a node
application. Socket overhead isn't going to be huge, so maybe that's the
right way to tackle this situation so that we always know the DB will be
there when we need it. For instance:
# App code stuff
db.open(..., function(err, obj)) {
# Do some small db operation
obj.close();
}
# More app code stuff
db.open(..., function(err, obj)) {
# Do some other small db operation
obj.close();
}
*Three*: another alternative would be to mix the two patterns - start up a
DB instance that lives for the duration of the app, and use that for
anything that's a user-driven event, such as a page request. That is to
say, only use the app-wide DB in cases where it's safe to assume the DB has
had time to load. Then for any DB hits which must happen at the absolute
beginning of the application (when we can't even be sure 100ms have passed
since the db.open() call was made), we open and close a separate DB handle.
There are probably other options, but these three are all I've come up with
so far. Is there an established best practice? If not, what would others
doing similar things recommend?
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
