Making Node.js operational

It occurs to me that much as the node.js community and the usage grow, lots of java or other developers still figure it as premature and reject it for enterprise applications.

To some extent, I found their conservation reasonable, and the major reason for that could be the operational gap. A fundamentally different architecture requires a corresponding operational model to help the application scale, and to be fault-tolerant and reliable as a qualified candidate for enterprise application.

Here’s something that’re on their way to eliminate the concerns, but might still have a few miles from the perfection.

Cluster is a major step forward for node.js to take the full power of commodity hardware today, and with the capability of sharing ports, workers could be forked identical to each other, which allows them to be dead, and reborn.

Forever is an interesting effort, it complies with the practical world that everything “dies”. As long as we could programmatically restart them, they’re technically undead.

Node-inspector is such a powerful tool, which not only allows for debugging at development phased, but also possibly at PRODUCTION runtime. The only problem I ran into was that a breakpoint could not be added till the javascript resource has been loaded. If we’re debugging in user request, that’s not much of a problem, coz mostly likely, all resources have been loaded by then. But the assumption doesn’t hold when we’re debugging at application starts or module loading time. The debugger API from node or the debugging protocol of webkit isn’t a blocker, in fact, based on the “script loaded” events, it’s possible to apply the breakpoints at then. It probably just need some UI enhancements to allow loading sources from elsewhere and do a mapping of the resource (based on module structure possibly)

Logging is a catch, we don’t like it till we need it. I have no problem with the active logging modules available, they shifted most of the java logging concepts nicely. What I found as a problem is in fact, such shifting neglected a fundamental difference, the fact that single thread could handle multiple requests at the same time. It’s a mess that we logged if doing no change, but unlike java’s multi-threaded model, where it’s safe to assume that a user request is dedicated to a thread till its end, and therefore, a common practice is to put the thread id as part of the log to correlate logs within a user request. Better yet, the api to do the logging doesn’t need to take thread information at all, coz it’s there whenever you ask Thread.currentThread();

Unfortunately, node doesn’t have such model, never would it be like that, and when you’re using Express or framework alike, correlate logs that belong to the same user request becomes pretty difficult. Because there’s no Thread, no ThreadLocal at all. And when you start io operation with callbacks, your  initial req, res are usually excluded from those callbacks (depends on whether you need them or not for application logic). It would look pretty odd, if I ask you to pass “req” e.g. along with the callbacks just for the sake of logging, but unless you do so, I don’t know a better way to relate your logs to this particular user request.

A slightly better way compared with writing your levels of callbacks as function(arg1, arg2, … req) is to use “this” scope, but it assumes that “this” scope isn’t being used by callback function. And a convention could be formed for node application’s callbacks that “this” is tied with “req”, to do that, simply use Function.prototype.bind as such:

app.get(“/”, function(req, res){

someAppLogic(req, res, someCallback.bind(req));

});

function someCallback(){

logger.log(new Event(this, “callback”));

}

This isn’t good when “this” is reserved for other purpose, none is this performant, as #bind is creating a new function on the fly, but it’s an effective way to group all of your logs under each request, let you make some sense of it.

 

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s