By Louis Simoneau

Node.js is the New Black

By Louis Simoneau

If you’ve been paying attention to news about web technology in the last year, you’ve most likely heard the name node.js mentioned at least once or twice. What happened next probably went like this: you asked, “What is it?” and someone (or Google) told you that it was a way to write web servers using JavaScript. If that didn’t scare you away, you might then have asked, “Why would you want to use it?” and the answer might have been along the lines of it taking advantage of non-blocking, event-driven IO to enable high concurrency in long polling or comet-based applications.

At which point you stopped asking questions. I don’t blame you. To help break apart that wall of jargon, here’s my attempt at explaining what node.js is and why you should be paying attention to it.

So here’s how it is, how it’s always been: a browser sends a request to a website. The site’s server receives the request, tracks down the requested file, performs any database queries as needed, and sends a response to the browser. In traditional web servers, such as Apache, each request causes the server to create a new system process to handle that request.

Then there was Ajax. Instead of requesting a whole new page each time, we’d only request the piece of information we actually wanted. Okay, that’s an improvement.

But now think about how you’d go about building a service like FriendFeed, where each user’s feed is updating in real time, all the time. The only way that’s possible is if each user has an active connection to the server at all times. The simplest way to do that at present is through long polling.

Long polling essentially tricks HTTP into acting like a persistent connection: as soon as the page loads, it fires off an Ajax request to the server, even if the page doesn’t want anything in particular. But, unlike a normal Ajax request, the server doesn’t respond right away. It just waits, and fires back a response only when it has something new it wants the browser to display. For example, as soon as one of your friends adds a new post, the server returns the response telling the browser to update its display. As soon as the browser receives the response, it shoots back another request. This way the browser is always waiting for a new event to happen on the server side.

Now think about what that means for a traditional web server like Apache. For each and every user connected to the site, your server has to keep a connection open. Each connection requires a process, and each of those processes will spend most of its time either sitting idle (consuming memory) or waiting on a database query to complete. This means that it’s hard to scale up to high numbers of connections without grinding to a near halt and using up all your resources.

So what’s the solution? Here’s where some of that jargon from before comes into play: specifically non-blocking and event-driven. What those terms mean in this context is less complicated than you might fear. Think of a non-blocking server as a loop: it just keeps going round and round. A request comes in, the loop grabs it, passes it along to some other process (like a database query), sets up a callback, and keeps going round, ready for the next request. It doesn’t just sit there, waiting for the database to come back with the requested info.

If the database query comes back — fine, we’ll deal with that the same way: throw a response back to the client and keep looping around. There’s theoretically no limit on how many database queries you can be waiting on, or how many clients have open requests, because you’re not spending any time waiting for them. You deal with them all in their own time, and that’s what event-driven means: the server only reacts when an event occurs. That could be a request, a file being loaded, or a query being executed — it really doesn’t matter.

FriendFeed uses a non-blocking framework written in Python, called Tornado, to do this. The nginx web server also behaves in this way. Node.js, however, has an ace up its sleeve: because it’s using JavaScript — running on Google’s crazy-fast V8 engine — it never needs to worry about whether a request it makes to another piece of code might cause the loop to block up. The reason is that JavaScript is intrinsically event-driven. Think about it: when you write JavaScript for the browser, you’re just attaching event handlers and callbacks. That’s the way the language was designed.

Node.js is still in its infancy, so if you want to write an application based on it you’ll need to do some fairly low-level coding. But with the impending arrival of WebSockets in next-generation browsers (eliminating the need for long polling altogether), this type of technology will only become more important on the Web. I hope I’ve given you the incentive to start messing around and getting your head around these concepts.

  • Louis,
    This is a great article on the next step in web/app development. After reading this I’m heading over to nodejs to see what they’re all about.

  • arts-multimedia

    Very interesting article and well explained. Thank you very much.

  • Nobody really does long-polling in the real world, do they? Surely that’s architectural suicide … using up an entire socket just for one user?

  • picohax

    Very nice article.
    node.js, and event-driven servers explanation done very well in simple plain English.
    It’s basically all about pipelines/queues – of events, of instructions, of requests, of responses.
    IOW, queues rule everything, like a multitasking OS running on a single core processor, like Windows message queue, maybe.
    (I think that we need some kind of infographics and animations to show these things using HTML5 canvas and animations. That would be awesome. Alternatively one could use AIR.)

  • Dazza

    It would be really nice to see more than just commentary on something like NodeJS. How about a tutorial?

    And this I believe is the problem with NodeJS.

    Yes, there’s plenty of modules built for it, it’s screamingly fast and the potential is amazing. But… How many ‘regular sites’ would need NodeJS at their core?

    And is it easy to develop with?

    Right now, I think moving parts of your site to use a different DB such as Mongo or Couch DB to solve certain performance issues makes more sense.

    • Louis Simoneau

      Yep, I agree. It’s way to early to start using for regular web projects where you just need a speed boost. But if you want realtime updates, and plan on having more than a few dozen users online at a time, one of these newer technologies is worth looking into. We definitely plan on publishing a tutorial article on node.js in the near future. Stay tuned!

  • levan

    so how soes thos ‘non blockingl server do server push without long polling ?

    • By continual polling – you request a data update from the server on a timeout, say every 30 or 60 seconds.

      I was under the impression that that’s the only practical way of doing it. Obviously not :)

    • EastCoast

      If you have a html5/flash web socket on the client side then you don’t need to poll at all, you can just respond to the message events as they occur.

  • Code Junkie

    Oh wow… This reminds me of when I started hearing about jquery and other javascript frameworks in college. It’s kind of like thunder on the horizon. I’m excited!

  • bellasys

    I like that you communicated at a consistent level, which is helpful to someone like me who hasn’t been excited about Node because I have favored Python (one, for MEL frameworks)… so even though I get the hard jargon and the apparent value of what Node offers as a framework, without an article like this I may never have looked at it seriously. I’m glad I did.

Get the latest in Front-end, once a week, for free.