Mmmmkay… So, if you know what Node.js is… you see where I’m going (this isn’t going to be anything in-depth so you can move along). If you don’t, you’re likely saying, “but I already have an httpd… I use Apache/IIS/Nginix/Lighttpd.” If you’re not in one of these camps, you’re probably wondering what the heck httpd is…

Node.js is an event-driven I/O server-side JavaScript environment based on the V8 JavaScript engine (thank you wikipedia). What it serves to do is listen to RESTful requests on a given port and perform actions based upon those requests. This isn’t anything different than a HTTPd server which does the same, but specifically for HTTPd REST statements. Node.js is designed to generically handle REST statements.

Unlike most JavaScript that you’re familiar with, Node.js sits on your server and handles RESTful statements (likely HTTP/S) just like your web server does. (“… but … why” you ask?) The simple answer is that building an entire stack can be resource intensive on your server. If you can provide a simple response without building an entire stack, you can save seconds of response time and megabytes of RAM. This efficiency comes from the simple fact that you can build your own webserver with only the parts that you need. This makes Node.js lean and mean.

“Well sure,” you say, “of course I can write my own web server and have it be ‘lean and mean,’ but who wants to write their own web server?” What if I told you that you could do it in six (or less) lines of JavaScript? Yeah, now you see what I’m getting at …

So, what does that have to do with Drupal?

Drupal and Apache are great, but they are heavy. There’s no reason to bring out a 550’ crane to do your lifting when you could just as easily do the job with your thumb and index finger. Rather than using these two, you can purpose build small webservers to do small specific tasks.

Like WHAT tasks? Everything needs the full stack!

Well, not everything… One thing that Apache is particularly poorly suited for is handling “long-polling” as a method of being able to keep connections open between the web server and the client. This is because of Apache’s specific architecture which quickly becomes tied up with requests that are being held open until the server simply stops responding to new clients. Node.js (and several other custom solutions) solve this by performing non-blocking handling of requests. There are numerous places that you can read about that limitation on the general purpose Apache httpd server. Yes, you can build a httpd server with tons of different languages. However, with Node.js, you can do it quickly, with very little code and to the specific task that you need it to fill. Compound this with a great development community that has sprung up around Node.js and you have a recepie for greatness.

Conclusion

I know Node.js can’t do everything… well, maybe it can, but it probably shouldn’t. However, it fills a niche that I think is increasingly necessary to solve interactivity issues in client-server architectures. I’m just beginning with Node.js and how it can work into the picture (if you’re a Node.js expert, feel free to set me straight if there’s something I missed or have wrong). I’ll be posting more about some of the ways that I’ve seen Node.js used in the near future as I explore it further.