Tags: Node.JS »»»» Node.x »»»» Event Driven Asynchronous »»»» Server-side JavaScript
Node.js is getting a lot of excited attention, but is it the only way to build an event driven server? For example the other day I summarized some work by Twitter to re-architect their systems including an event driven asynchronous server, but that server was written in Java and in general the article proved that a single-language solution like Node.js might not be the best because there are plenty of useful languages besides JavaScript (see Java, Twitter, and asynchronous event driven architecture). Today on Twitter I saw an announcement of Node.x, which is a general purpose framework for asynchronous event driven programming but rather than built on top of Node.js/V8 it's built on top of the JVM. And by being on top of the JVM it immediately opens the door to a multi-language solution, where Node.js is a single language solution.
Take a look at the project site however and we see immediately that the project is squarely in the stage where the originator is building a proof of concept to see if it's feasible. Node.js was at this stage 2 years ago. First observation is that they have a heap of a lot of catching up to do.
Since one of the attractions to Node is compact succinct code let's look at one of the example programs (the current examples are all in Ruby):
require "http"
include Http
# A trivial HTTP server which justs writes back some HTML for each request
server = Server.create_server { |conn|
conn.request {
|req, resp| resp.write_str("<html><body><h1>Hello from Node.x!</h1></body></html>", "UTF-8").end
}
}.listen(8080)
puts "hit enter to stop server"
STDIN.gets
server.stop
I don't know Ruby, but this is pretty straightforward anyway, a simple Hello World along the lines of the Node.js Hello World example:
var http = require('http');
http.createServer(function (req, res) {
res.writeHead(200, {'Content-Type': 'text/plain'});
res.end('Hello World\n');
}).listen(1337, "127.0.0.1");
console.log('Server running at http://127.0.0.1:1337/');
This has some promise. Of course there's more to Node than just succinct coding, there's also performance and the growing ecosystem of modules. In terms of performance I'm confident the JVM will match or beat V8 especially considering that Hotspot has perhaps 10 years of development maturity behind it. However as I noted earlier, the Node community is moving ahead at warp speed in building the ecosystem of modules, and Node.x isn't even to the starting gate. One key value of a programming platform is the ecosystem of libraries or tools with which developers build their applications; the more of these the more valuable the platform.
Now, let's start down the list of features where they say what Node.x is:
A general purpose framework that uses an asynchronous event based style for building highly scalable network or file system aware applications and Everything is asynchronous. Embraces the style of node.js and extends it to the JVM. Think node.js on steroids. Plus some.: That's quite a mouth-full, but basically they're saying they're going to implement Node on the JVM. That sentence is basically describing Node, and obviously the name (Node.x) is a very large hint they're taking a cue from Node.js.
Polyglot. The same (or similar) API will be available in multiple languages: Ruby, Java, Groovy, (Python, JS, Clojure, Scala): The JVM is a multi-language platform with dozens of available languages. There is commonality in the form of the Java runtime library, and programs written in whatever language you like can access Java classes to use the already existing ecosystem of Java libraries. There is even a JavaScript interpreter built on top of the JVM (Rhino) and in theory one could borrow the Node.js module system to run on top of Rhino on the JVM.
Goes with the recent developments with InvokeDynamic in Java 7 and bets on the JVM being the future premier runtime for dynamic languages.: Hm, I have my doubts about the future of the JVM being very bright but I'm not willing to bet that it will die. In any case the JVM is today a robust very mature platform with a ton of excellent features and stability already baked in due to the 15 years or so of refinement.
True threading. Unlike node.js, Python Twisted or Ruby EventMachine, it has true multi-threaded scalability. No more spinning up 32 instances just to utilise the cores on your server.: Here's a strong departure from Node.js. Node doesn't support multiple threads so to fill out all the cores on your server you have to spin up multiple Node processes. The JVM has supported threading from the beginning and has Doug Lea's Concurrency library baked in.
There is a trade-off here however. Thread based concurrency increases the complexity of the system. Node.js modules don't have to worry about other threads mucking with data structures while executing code inside the module, because there aren't other threads. But a Node.x module would face that issue because the JVM uses threads, and they plan to exploit threads.
On the other hand, in Node.js concurrency is implemented in part by the asynchronous event loop, and in part by spinning up multiple processes. The multiple processes don't share memory which has several effects. One effect is that there's no chance for deadlocks or race conditions other issues with concurrent updates to data structures. Another effect is that, assuming the multiple processes are working together to implement the same service, any shared data has to be kept in some shared data store like a database.
https://github.com/purplefox/node.x
http://groups.google.com/group/nodex-dev/browse_thread/thread/12c071b109db377c
Books by David Herron
(Sponsored)
