Tag Archives: Reactor Pattern

OK, so I finally get Node.js. It’s about a totally different kind of server software.



Javascript on the server? What’s the point? PHP is the winner for medium-sized Free Software web applications. Java is the language of choice for the Enterprise. Python and Ruby are trendy alternatives. Why Javascript? These were my initial thoughts about server-side Javascript and I really haven’t thought about it since.

Meanwhile, I have been programming pretty much full time this year on Single Page Applications in Javascript using Sencha ExtJS, jQuery, and Twitter Bootstrap. The reality of how different this style of single-threaded but asynchronous programming is has been a real eye-opener. Javascript happens to be the language, and it is well-suited to the job. I am perpetually defining anonymous callback functions inline that get passed as arguments to other functions. This an essential part of browser-based programming because those functions may take a while to return because they are making network Ajax calls back to the server, and we don’t want to lock up the user interface while waiting.

I had always associated this kind of complex asynchronous event-driven programming with multi-threaded or multi-process architectures. It has to be that way right? Even many Unix system calls block on I/O (read(), write()), so how could it be any different? ¬†Javascript programming on the browser doesn’t block on anything. It is rich in callbacks, keeps track of the variable scope for those callbacks, and does it all in a single thread. Client-side Javascript is introducing a whole generation of developers to this style of development.

Then I went to a conference (devLink) in Chattanooga, TN last month. Patrick Chu, a Sencha engineer and trainer, gave a talk on Node.js. Other speakers also talked about Node.js, and it became clear to me. Node.js is not just about satisfying someone’s preference about what language they want to write their server code in. It is about a totally different kind of server software. Node.js NEVER BLOCKS ON I/O. From the ground up, it is written to use the CPU at full speed. When waiting on I/O is needed, a callback is required. System calls are only EVER called in their non-blocking forms. In design-pattern-terms, this creates a programming approach conforming to the Reactor Pattern. This makes it incredibly easy to write efficient, responsive, event-driven server software of all kinds (not just web/http serving software) that is TOTALLY DIFFERENT architecturally from PHP, Java, Python, Ruby, or any other languages that read and write files and network sockets and database handles. These languages either ignore processes and threads (leaving the intricacies of server development to the application programmer) or make them first class citizens of the language (creating complexity to account for the blocking nature of I/O).

Why do we create 30 to 100 Apache workers to keep a machine busy that has 8 cores? It’s because the whole architecture of Apache and any software similar to it (including all web servers I had ever seen) is trying to make up for the fact that each of the processes is regularly blocking on I/O. With Node.js, an 8 core machine can be fully utilized with 8 Node processes.

I later went and listened to some talks by Ryan Dahl, the developer of Node.js to learn more. It turns out that what was driving him was how to create server software that never blocked on I/O. He worked in several languages before coming to the point of doing it in Javascript. What’s special about Node.js is that it never blocks, not that it enables server software written in Javascript. However, the fortuitous thing about the choice of Javascript is that a generation of developers who are necessarily learning to do this new kind of programming on the browser have a natural transition to the server.

The imperative of scaling a system requires that we move beyond a single process. The Node community is addressing these issues with load balancing, inter-process communication, and central coordinating servers (e.g. redis). Thus, while Node.js moves beyond the single process, it easily moves beyond the single server.

Node.js is not just about Javascript on the server. It is about a whole new way of server programming.

All of the high performance and creative web-server-side software I write from now on  will be in Javascript on Node.js.

Leave a comment

Filed under Uncategorized