Intro to Node.JS for .NET Developers
Microsoft announced out-of-the-box support for Node.JS on Windows Azure on Tuesday; we pushed both an official Node.JS SDK for Windows Azure services (table storage, blob storage, and queues) and some tools for creating and managing Node.JS roles on Windows Azure, both of which are available through the official Windows Azure page on Github.
I’ve been playing around with Node for a short while and have the pleasure of working with some great startups that utilize Node heavily in production, so I wanted an opportunity to explain to my fellow .NET developers why they should be excited about Node support on Azure and how they can put it to work for them.
Node at a Glance
If you want to spend 90 minutes and get a full 100-level understanding of Node, check out The Node Beginner Book. If you’re fine with the footnotes, keep reading.
Node is an asynchronous distributed programming platform built on top of Chrome’s V8 JavaScript engine (the same engine used to parse and execute client-side JavaScript inside Chrome.) Node is actually server-side JavaScript, but its syntax and prose are familiar to every web developer to some extent.
Node’s true innovation is its evented + asynchronous I/O model.
var http = require('http');
http.createServer(function (req, res) {
res.writeHead(200, {'Content-Type': 'text/plain'});
res.end(myJavascriptObject.getSomeStatusInfo());
}).listen(1337, "127.0.0.1");
The primary method of any Node application runs a single-threaded continuous event loop (the .listen method of the HTTP server), which farms out long-running tasks to worker threads (the anonymous function) which callback the main event loop once they’re finished:
There are three major advantages to this model:
- The main event loop uses a single thread to handle multiple concurrent connections, which makes the overhead of Node.JS grow relatively slowly as the number of requests it has to serve increases as there’s no OS thread / process initialization overhead;
- All long-running tasks (network I/O, data access, etc…) are always executed asynchronously on top of worker threads which return the results via callback to the event loop thread; and
- JavaScript’s language features (functions as objects, closures, etc…) and Node’s programming model make this type of asynchronous / concurrent programming much easier to utilize – there’s no thread management, no synchronization mechanisms, and no message-passing nonsense. This eliminates a lot of pitfalls that most developers fall into when attempting to develop concurrent applications.
Using Node.JS with .NET
So, you’re a veteran ASP.NET MVC or WCF developer… Why should you be interested in taking a look at Node?
First, Node is fully supported in environments .NET developers are familiar with. Node runs on Windows; Node can be run as a managed module inside of IIS; and Node can now run on Windows Azure. There’s even a NPM package for having Node.JS interop with SQL Server.
Second, Node does a great job tackling vertical issues like real-time notifications, web sockets, and other scenarios that aren’t easily addressed through existing .NET technologies (although SignalR is pretty cool.)
Node isn’t a replacement for everything – frankly, it’s not a great solution for heavy web + database CRUD applications or for serving static content.
Here are some scenarios that I like for Node:
- Handling multiple concurrent connections (web sockets, handling events from real-time messaging systems [ZeroMQ / Azure Service Bus], anything with socket programming…)
- High-volume, small response-size systems – think of a real-time logging system where you have to write millions of messages an hour and only send small ACK response objects back to the caller – Node.JS is perfectly suited to handle this;
- Real-time Pub/Sub systems – if you have an application that is heavy on notifications and needs to do it in real-time, Node is a great choice given its penchant for getting in and out of requests quickly.
Need a pragmatic example?
Take a close look at Socket.IO, arguably the best solution for working with web sockets and long-polling available on any platform.
If you have an application where real-time notifications are important like a messaging application or a social game, then running Socket.IO alongside IIS on your boxes gives you a significantly simplified solution both on the client (the Socket.IO client is backwards compatible all the way to IE5.5) and the server for handling socket connections and routing, and it takes a minimal amount of resource overhead to do it.
I’m going to be doing some more work around Node.JS and Azure in the New Year, so if you have any questions or comments please feel free to hit me up in the comments here.
Want to get started with Node.JS and Windows Azure?
If you want to try out Node.JS on Azure, sign up for the Windows Azure free trial and install the Node.JS Azure SDK via Web Platform Installer.
Discussion, links, and tweets
I'm the CTO and founder of Petabridge, where I'm making distributed programming for .NET developers easy by working on Akka.NET, Phobos, and more..
Tweet Follow @Aaronontheweb