A Conversation Example

To help you understand how events work in Node.js compared to traditional threaded webservers, consider an example of having different conversations with a large group of people at a party. You are acting the part of the webserver, and the conversations represent the work necessary to process different types of web requests. Your conversations are broken up into several segments with different individuals. You end up talking to one and then another, then back to the first and then a third, back to the second, and so on.

The conversation example works well because it has many similarities to webserver processing. Some conversations end quickly (for example, a simple request for a piece of data in memory). Others are broken up in several segments that go back and forth between individuals (much like the more complex server-side conversations). Still others have long breaks while waiting for the other person to respond (like blocking I/O requests to the file system, database, or remote service).

Using the traditional webserver threading model in the conversation example sounds great at first because each thread acts like a clone of you. The threads/clones can talk back and forth with each person, and it almost seems like you can have multiple conversations simultaneously. There are two problems with this model.

The first problem is that you are limited by the number of clones. If you have only five clones, then to talk with a sixth person, one clone must completely finish its conversation. The second problem is that there is a limited number of CPUs/brains that the threads/clones must share. This means the clones sharing the same brain have to stop talking/listening while other clones are using the brain. You can see that there really isn’t a very big benefit to having clones when they freeze while the other clones are using the brain.

The Node.js event model acts more similarly to a real-life conversation than does the traditional webserver model. First of all, Node.js applications run on a single thread, meaning there is only one of you—no clones. Each time a person asks you a question, you respond as soon as you can. Your interactions are completely event driven; you move naturally from one person to the next. Therefore, you can have as many conversations going on at the same time as you like and bounce between individuals. Second, your brain is always focused only on the person you are talking to since you aren’t sharing it with clones.

So what happens when someone asks you a question that you have to think about for a while before responding? You can still interact with others at the party while trying to process that question in the back of your mind. That processing may impact how fast you interact with others, but you are still able to communicate with several people while processing the longer lived thought. This is similar to how Node.js handles blocking I/O requests using the background thread pool. Node.js hands blocking requests over to a thread in the thread pool so that they have minimal impact on the application-processing events.