Recently I needed to start a server written in Node.js. This server was deployed on Ubuntu 12.04, and I wanted it to be started using the system's init system. Yet I also wanted the safety of Forever, a script manager for Node.js.

Ubuntu still supports the classic SysV init style, but it also now supports the far more sophisticated Upstart system. It is appealing for a few reasons: One is that it feels simpler and cleaner. Another is that it is more powerful and easily more configurable. I decided to use it for my scripts.

This article explains how to use Upstart, Forever, and Node.js together to run a Node.js server as a daemon process that is automatically started at system startup, and automatically stops at shutdown or reboot.

On Linux (and UNIX), to open a port with a number less than or equal to 1024, traditionally a program must run as the root user. This impacts web applications, which use ort 80 (HTTP) and port 443 (HTTPS) to do business. Many programs (Apache being a great example) use this by running a master process as the root user, and farming work off to helper processes that run with lower privileges. But Node.js is designed to work on a single-process model. So how do you run Node.js apps on low ports without running the script as root?

I looked at a number of solutions, and one suggested by my company's security team seems to be the best solution: For operating systems that support capabilities setting (like Ubuntu 12.04 and later), you can configure the operating system to allow non-privileged apps to listen on low ports. Here I show how to do it, and then briefly explain what is going on.

In its minimalism, Node.js does not have libraries to perform some common tasks. One such task is taking a string (or Buffer) of data and interacting with it as if it were a Stream. Here is a simple StringReader implementation that illustrates a no-nonsense way of exposing a string as if it were a stream.

Here's how it works at a high level:

• A StringReader can take either a String or a Buffer.
• For Buffer objects, it can also handle different encodings. You can use setEncoding() to set the encoding. When reading the stream, the given encoding will be used. (In other words, you can give it a Buffer and read it back as a String)
• The resume() method is the workhorse. A StringReader is paused by default. Only when resume() is called will it begin emitting events. It will do the following:
  • Emit the entire String or Buffer in the first (and only) data event.
  • Emit the end event, indicating that there is no more data.
  • Emit the close event, indicating that there's nothing more this reader will do.

With this description in mind, let's look at the code.

The new pre-1.0 version of Pronto.js has been released. This is the first release of the 0.3 branch.

Pronto is a high-performance asynchronous framework for Node.js.

Here are the big new changes:

• Pronto.js now has an HTTPS server.
• The Pronto logger is considerably more sophisticated. While cxt.log("foo", "debug") still works, so does cxt.log("Hi, my name is %s.", "Matt", "debug"). Loggers can also serialize data into Node's inspect format as well as into JSON.
• The web server no longer parses all POST and PUT data. Now it only parses content that it understands, and that is less than 1M.
• There is a new BufferedReader readable stream. This should be used any time you need to buffer a stream for more than a tick.

The 0.3 branch is now semi-stable, and so has been released to npm.

One year ago I listened to Allen Wirfs-Brock of the Mozilla Foundation deliver the closing keynote for StrangeLoop 2011. Wirfs-Brock's central claim was jarring. Keep in mind, this is a conference whose attendee list is dominated by language designers, database architects, PhDs, and people whose credentials make the term "senior" seem like a gaping understatement. Yet in front of this crowd, Wirfs-Brock unabashedly coronated JavaScript the new king of programming languages.

I did not buy it. But a year later, I'm changing my mind.

Pronto.js is a JavaScript framework for Node.js designed for writing fast, efficient, asynchronous, component-based applications. It can be used for web applications, REST API servers, command-line programs, and so on.

Pronto.js is based on the idea that code consists of three major conceptual pieces. First there is a route. A route executes a chain of commands. So writing a Pronto application is all about writing commands, and then organizing them into chains mapped to routes.

Here we look at how to write commands. In this article, we will build a small sample app composed of two commands chained together in a single route. We'll highlight how to write commands and how to share components through the context.

Pronto.js is a JavaScript library for application building. Designed for Node.js, it makes writing high performance asynchronous applications much easier. And it introduces modularity so that you can build applications with highly reusable components. ConsumerSearch.com (part of About.com, a New York Times company, etc.) uses Pronto to communicate with their mobile apps.

How Pronto Works

Pronto doesn't use the MVC (Model View Controller) pattern prominent in many applications. There are several reasons for this, but the big one is simple: MVC isn't a terribly good fit for Node.js. If you really like MVC, you can actually reproduce it conveniently in Pronto.js, but the framework itself doesn't make you use it.

Instead, Pronto combines two other patterns: Front Controller and Chain of Command.

• Front Controller: This is basically the "router" part of most MVC implementations. In a nutshell, it sits at the front of the application and maps incoming requests to the code that can handle those requests.
• Chain of Command: This pattern takes a particular request and executes a series of commands in response. Each command builds on the previous command, thus they act like a "chain".

A First Pronto Project

To get started with Pronto using Node.js, give this a try. What we are going to do is build a very simple "Hello World" application. This doesn't get into the details of working with a context or writing your own commands, but it will help you get started.

In JavaScript -- especially of the Node.js sort -- it is a common pattern to put a functional callback as the last argument in a parameter list. For example, we might define a function that looks like this:

/**
 * @param {String} data
 *   Data to save.
 * @param {Object} properties
 *   Properties to be added to the object.
 * @param {Function} fn
 *   A callback called when the object is saved.
 */
function save(data, properties, fn) {
  // Do something with data and properties
 
  fn('All done');
}

What do you do, though, if properties is optional?

I was thrilled to read the story at Mobile Drupal about how ConsumerSearch is using Pronto.js to expose their huge Drupal content to their mobile application.

Pronto.js is designed to be a high performance asynchronous application framework that makes it simple to chain together components to build sophisticated application logic. It's the JS equivalent of the PHP Fortissimo framework.