SalientBlue

While my last post cast a wide net, this post will start the process of focusing in on just a couple things: first nodeJS and later, Angular.

So what is nodeJS? Based on my (very little) experience, it is a tool for building lightweight, highly-concurrent, non-blocking, asynchronous services in JavaScript. It supports many common protocols like TCP, HTTP, HTTPS, TLS(SSL), DNS, IP/UDP, and TTY. Its elegance is in “hiding” the event loop and threading, and in it’s lack of support for parallel processing. Node’s philosophy is to handle parallelism by spawning new OS processes. A single node process generally handles many hundreds or even thousands of connections (depending on how much work they do). Once a node process is saturated, scaling is achieved through starting another process. In Ryan Dahl’s words, “a single node handles many concurrent connections, but it does no parallel work. Multiple Nodes are required to do parallel processing, effectively forcing a shared-nothing model with process boundaries.”

This approach appeals to me. I have always felt that a loose confederation of small, simple services that can be aggregated to provide more complex offerings is a much better approach than creating a single, monolithic web server that handles every service request an enterprise can imagine (and creates a single point of failure). Using nodeJS, services can be independent which is more robust, easily scales by spooling up more processes either on the same machine or different machines, and makes the overall system much easier to extend and maintain. This also makes nodeJS an excellent tool for cloud-based services, where scaling is accomplished by spooling up new instances of virtual machines on an as-needed basis.

Having said all of that, I’m not proposing nodeJS is the perfect fit for any situation. However, I do think that just about any organization would find it a valuable tool, even if just used for a couple simple services. I can envision a migration path where some of the simpler enterprise services are rewritten as individual node processes and removed from their monolithic web server.

Here is the list of nodeJS resources I promised in my last post:

• Ryan Dahl’s 28 July, 2010 Google Tech Talk (YouTube) is an excellent introduction.
• The nodeJS GitHub wiki has a comprehensive list of resources
• antinode: a configurable static page web server created on top of nodeJS. I plan on using this as a reference as I build on the “Hello World” web server below
• Mastering nodeJS: a free ebook (work in progress) covering the details
• Naked JavaScript blog’s nodeJS write-up: covers installing and creating a few basic services
• Caolan McMahon’s blog post on unit testing nodeJS: he uses nodeunit. I’m going to try Jasmine first, but I’ll probably reference Caolan’s post along the way.
• Ryan Dahl’s slides from his JSConf 2010 presentation (PDF)

In my last post, I also promised the code for my first HTTP server written in nodeJS (it is very close to the example provided on the nodeJS web site):

var http = require('http');

http.createServer(function (request, response) {
  response.writeHead(200, {'Content-Type': 'text/plain'});
  response.end('Hello NodeJS!');
}).listen(80);

console.log('Server running on port 80');

If you’re running node on an EC2 instance (as I outlined in my last post) and want to use port 80, you’ll have to “sudo node <filename>”. A non super-user doesn’t seem to have permissions to start a service on that port. If you’d rather run the server locally you’ll need to change line 6 above to:

}).listen(8000, '127.0.0.1');

Of course you’ll also need to append the port number to the URL in your browser: http://127.0.0.1:8000.

In my next post I’ll start exploring some of the details of nodeJS, demonstrating non-blocking, TCP, HTTP, File IO, and more!