As usual JSConf.eu was one of the best conferences I've been to this year. It's always a delight to hang out with some of the smartest JavaScript coders on the planet, and doing it in the very trendy city of Berlin was a nice bonus. There are a few great recaps of JSConf so I'm not going to focus on those; instead I'm going to expand the talk I gave.
Programming inside an event loop is something most programmers only have a passing familiarity with. Node.js is quickly gaining traction as a very popular event loop-based server for JavaScript. It gives people the ability to write JavaScript on the server, which has access to things like the HTTP stack, TCP, file I/O, and databases. However the kind of programs that we write in this context tend to be very different from the kind of programs we write for browser-side applications or sites.
In the browser, the bulk of the program tends to be involved with setting up the user-interface, and then there are some small event callbacks that are enacted — most typically, based on user interaction with the browser. For example, when the user clicks Submit on a form, we intercept the click and validate their submission.
There is an important point here: in most browser programming, programmers are only dealing with events caused by the user, and the user can only do so many things at once. Moreover the callbacks for those events tend to be very discrete and don't cause other events. Some libraries, such as YUI, have custom event support. But it is often thought of an advanced feature.
On the server, however, there isn't a user to drive a variety of interactions. Instead we have a whole range of reactions to take on many different kinds of events. Node.js takes the approach that all I/O activities should be non-blocking (for reasons we'll explain more later). This means that all HTTP requests, database queries, file I/O, and so on, do not halt execution until they return. Instead they run independently and then emit an event when the data is available.
This means that programming in Node.js has lots of callbacks dealing with all kinds of I/O and then initiating other callbacks for other kinds of I/O. This is a very different from browser programming. There is still a certain amount of liner setup, but the bulk of the code involves dealing with callbacks.
Because of these different programming styles, we need to look for patterns to help us effectively program on the server. That starts with the event loop, so let's take a look at that in more depth.
I think that most people intuitively get event-driven programming because it's like everyday life. Imagine you are cooking. You are chopping a bell pepper and a pot starts to boil over. You finish the slice you are doing, and then turn down the stove. In daily life, we are used to having all sorts of internal callbacks for dealing with events, and yet, like JavaScript, we only do one thing at once.
Yes, yes, I can see you are rubbing your tummy and patting your head at the same time, well done. But, if you try to do any serious activities at the same time, it goes wrong pretty quick. This is like JavaScript. It's great at letting events drive the action, but it is "single-threaded" so only one thing happens at once.
Another way to think about this event loop is a post (or mail) man. To our event-loop postman, each letter is an event. He has a stack of events to deliver in order. For each letter (event) the postman gets, he walks to the route to deliver the letter. The route is the callback function assigned to that event (sometimes more than one). However, critically, since our mailman only has a single set of legs, he can only walk a single code path at once.
Sometimes, while the postman is walking a code route someone will give him another letter. This is because the callback function he is code walking has emitted an event. In this case the postman delivers the new message immediately (after all someone gave to him directly instead of going via the post office so it must be urgent). The postman will diverge from his current code path and walk to the code path to deliver the new event. He then carries on walking the original event that emitted the event he just walked.
Let's look at another example. Let's give the postman a letter to deliver that requires a gate to be open. He gets there and the gate is closed, so he simply waits and tries again, and again. He's trapped in an endless loop waiting for the gate to open. But if there is a letter on the stack that will ask someone to open the gate so the postman can get through, surely that will solve things, right? 
Unfortunately it won't, because the postman will never get to deliver the letter because he's stuck waiting endlessly for the gate to open. This is because the event that opens the gate is external from the current event callback. If we emit the event from within a callback, we already know our postman will go and deliver that letter before carrying on. However, when events are emitted external to the currently executing piece of code, they will not be called until that piece of code has been fully evaluated to its conclusion.
We can use this to write a piece of code that creates a loop that Node.js (or a browser) will never break out of:
EE = require('events').EventEmitter;
ee = new EE();
die = false;
ee.on('die', function() {
die = true;
});
setTimeout(function() {
ee.emit('die');
}, 100);
while(!die) {
}
console.log('done');
In this example, console.log will never be called because the while loop stops Node from ever getting chance to callback the timeout and emit the 'die' event.
This is a really important piece of information, because while it's unlikely we'd program a loop like this that relies on an external condition to exit, it clearly illustrates how Node.js can only do one thing at once. And getting a fly in the ointment can really screw up the whole server.
Let's look at the standard Node.js code for creating an HTTP server:
var http = require('http');
http.createServer(function (req, res) {
res.writeHead(200, {'Content-Type': 'text/plain'});
res.end('Hello World\n');
}).listen(8124, "127.0.0.1");
console.log('Server running at http://127.0.0.1:8124/'
This code is the 101 example from the Node.js web site. It creates an HTTP server using a factory method in the http library. The factory method creates a new HTTP server and attaches a callback to the 'request' event. The callback is specified as the argument to the createServer.
What's interesting here is what happens when this code is run. The first thing Node.js does is run the preceding code from top to bottom. This can be considered the 'setup' phase of Node programming. Since we attached some event listeners, Node.js doesn't exit, but waits for an event to be fired. If we didn't attach any events, then Node.js would exit as soon as it had run the code.
So what happens when we get an HTTP request? When an HTTP request is sent to the server, Node.js emits the 'request' event that causes the callbacks attached to that event to be run in order. In this case there is only one callback, the anonymous function we passed as an argument to createServer. Let's assume it's the first request the server has had since it setup. Since there is no other code running, the 'request' event is emitted and the callback is just run. It's a very simple callback and it runs pretty fast.
Let's assume that our site gets really popular and we get lots of requests. If, for the sake of argument, our callback takes 1 second, then if we received 2 requests at the same time, they can't both be run at once, and the second request isn't going to be acted on for another second or so. Obviously, a second is a really long time, but as we start to look at real-world applications, the problem of blocking the event loop becomes more dangerous as we can see the damage it could have on users.
The upshot of this is that we want to keep Node.js as event-driven and non-blocking as possible. In the same way that an I/O event that can be slow should use callbacks to indicate the presence of data Node.js can act on, the Node.js program itself shouldn't be written in such a way that any single callback ties up the event loop for extended pieces of time.
The operating system kernel actually handles the TCP connections to clients for the HTTP server, so there isn't a risk of not accepting new connections. But there is a real danger of not acting on them.
This means that we should employ two strategies for writing Node.js servers:
- Once set up has been completed, make all actions event driven
- If Node.js is required to process something that will take a long time, consider delegating with web workers
Taking the event-driven approach works effectively with the event loop — I guess the name is hint it would — but it's also important to write event-driven code in a way that is easy to read and understand.
In the previous example, we used an anonymous function as the event callback. This makes things hard in a couple of ways. Firstly, we have no control over where the code lives; the anonymous function must live where it is attached to the event either via a factory method or the on method of an EventEmitter. The second issue is debugging: if everything is an anonymous event, it can sometimes be hard to distinguish similiar callbacks from each other when an exception occurs.
In part 2, we'll discuss how to write good event-driven code based on patterns that support our use of the event loop. If you can't wait until then, you can take a look at the slides from JSConf.eu:
It's been a pretty busy week in web tech! So here is some of the stuff happening this week and some good stuff that you might not have seen already.