Ptarmigan For Dummies, Part 1 - Introduction

NOTE! Updated 2011-11-27 to reflect 0.8.2.

I recently jumped on the node.js wagon and began browsing around for interesting ideas associated with it. (If you don’t know anything about node.js, stop reading now.) A few days ago I stumbled upon and immediately felt it might be a little game-changer; something to invest knowledge in so you can hang out with the cool guys at JSConf and to keep up appearance in spite of having turned 50 or so. But the lack of a more slowly paced introduction for guys and gals that prefer a little more smooth-talking before going hard core with code was frustrating, so I decided to take on a grand endeavor and write the very first “ For Dummies” blog entry. All for my own education. Well, voilá, here it is. If it’s helpful for someone else I’m happy.

What is is the brainchild of Marak Squires and it’s currently in version 0.8-something. But it’s not that new, Marak has been working on the idea since 2006, and it’s now in its 7th iteration. So there’s a lot of thinking and refactoring in it. Which, of course, explains its beauty.

To get started, let’s pull a quote from the worlds first blog entry by Charlie Robbins: is a full-featured I/O framework for node.js that enables a simple way to distribute your application across multiple node.js processes using the new EventEmitter2 API and leveraging the power of Crash-only software.

So the basic idea behind is to create a framework that enables use of small processes, each focused on solving one particular task, that forms building blocks for larger and more complex applications. Instead of tossing all functionality of a large, multi-IO application into one and the same program running in one process, you can build up your application piece by piece by gradually adding small processes that communicates by sending and listening to events.


Multi-process provides the I/O framework for doing exactly this in node.js. Each process is called a “hook” and implements a TCP server or client, each capable of sending event messages over a TCP socket, or just listening for events.

The Hook cloud

A major advantage of this cool and sassy approach is that applications will almost by magic become more robust and efficient. Since each of the processes run independent of each other, the system as a whole will not suffer if one process should crash. They are loosely connected only by sending and listening for events. also take good care to keep the hooks up and running by automatically restarting them if a crash occur. Also, since the application is divided into several separate processes it will make more efficient use of modern, multi-core hardware.

The first hook to start up automatically becomes the server hook, sometimes referred to as the parent hook. All events sent will be channeled through this server hook. After this, all launched hooks automatically becomes clients and connects to the server hook. You will later find out that you programmatically can setup a hook in many ways and let you, and not the launch order to decide who becomes server hook, but the automatic approach is fine for most of the time.

Hook server and clients

Now consider the server hook’s role for a while. It’s responsible for listen for all incoming events and re-distribute them to all clients, except the one that sent the event. So it becomes a single point of failure; should it go down for some reason, like adding new functionality to it or just crashing, the application as a whole will stop working since no events will be propagated.

It is thus fairly safe to say that a good design pattern is to have a server hook that does nothing more than just being the server. Don’t be tempted to add all sorts of stuff to it just to keep your “hook count” low. In his nice and short video tutorias (which are slightly outdated as they concern an older version), Marak calls it the “vanilla hook” and that’s a fitting label. It contains no custom code what so ever. In fact, it’s so simple that I can show it right now, you won’t faint:

var Hook = require('hookio').Hook;
var hook = new Hook();

This hook does nothing except being a hook. As long as it is started first and thus become the server hook, it will listen for incoming events and redistribute them to connected client hooks. That’s all. So with this said about the “vanilla hook”, I end this chapter with an updated illustration of what a application might look like. See you in next chapter! :)

Hook server and clients

blog comments powered by Disqus