Archive for June, 2015


Beginning on Node.js

Recently I started learning Node.JS as a result of a few projects developed on a startup I recently joined. We are using on some of our projects and it happens to be based on Node.JS. Also, while learning Backbone.JS and searching for a solution to unit test our Backbone.JS code I stumbled upon Sails.JS. Sails.JS drew my attention immediately, its productivity was stunning. Suddenly, Javascript, something that only recently I started to give some credit (due to Backbone.JS and some other frameworks but ALL focused on the UI), was looking as a promising solution for a great niche of application.

While studying the Node.JS platform I soon realized that some of the similarities between what can be seen on the Java <-> Android is true for Javascript <-> Node.JS. Node.JS happens to run Javascript code but it isn’t simply Javascript. The same is true for Android as we can’t say that Android isn’t simply Java. Java presumes a lot of things that isn’t possible on Android, eg.: ClassLoading on Android doesn’t work as on Java, it seems that you are limitted to a DexClassLoader (and as we are on the Dex subject it is THE sign that Android isn’t really Java otherwise it would simply run Java bytecode).

But what about Node.JS (I’ll refer to it simply as Node from now on)? Although Node runs Javascript it has some unique things that form the Node platform, one of them is the process global object. One of its most known functions is the process.nextTick(callback) that allows code to schedule callbacks to be immediately executed on the next run of the event loop (not exactly the next run but it is guaranteed to run before any I/O event). Another important characteristic of code running inside node – but this one was drawn ipsis litteris from javascript – is the run-to-completion. This characteristic allows javascript code to place event listeners on an EventEmitter without risking the event firing before the listeners are set since the I/O code would only be able to run on the next execution of the event loop. I’ve talked a lot about the EventQueue but I’ve not mentioned that Node runs on a single thread and this alleviates the issues related to thread contention but we STILL have race conditions since we have code running concurrently (between callbacks), eg.: if you have a code that checks whether a file exists (async code since it is I/O based) and downloads that file if it does not exist you may risk having that file overwritten since the callbacks that checks for the file must be run on after the other and then the two downloads would proceed as the file did not exist. So how to scale Node applications? Node provides a core module named cluster that allows for a model similar to Apache MPM Prefork.

Enough of Node for today… I’ll try to come back soon and talk about NPM (another node cornerstone) and Sails.JS since Sails.JS is a REALLY interesting framework that draws from a lot of best practices and concepts found on lots of other frameworks (and still produces really clean and organized code).



Blog Stats

  • 375,197 hits since aug'08

%d bloggers like this: