REST web service development with the Apache/Java/Spring/Maven/Hibernate stack is quite complex as each layer brings its own configuration requirements. The resulting size of the monolithic web app archive also tends to be massive, most of it as a result of chains of jar dependencies.
For small projects, you may end up writing more XML config for Maven and Spring than actual Java code! There’s also a learning curve involved in using Eclipse or Spring Source. Each element (the web container, IDE debugging prefs, JVM location and heap size, Maven sources) may need configuration that can distract from the functionality you need to write. Most Eclipse users I know keep a backup of IDE preferences & sometimes the entire Eclipse folder in case it needs to move to a different machine or drive.
I felt there must be something better out there that:
- Offers responsive web development
- Does more with less plumbing
- Is platform agnostic
- Uses human-friendly JSON for everything including dependency management
- Doesn’t need a PhD to enable debugging
- And well, more fun
So when I heard about Node.js, and saw Ryan Dahl’s 2011 presentation introducing Node to the world, I was intrigued and fired up my terminal to get the feel of it by hammering out a couple of apps… and I found myself wondering “It can’t be that easy”!
I built an N-session chat server up and running in less than 30 minutes with the following 30 lines and no compilation, written entirely in a plain text editor:
Here’s a screenshot of it in action:
I then began investing the time to read and learn more about Node & it’s ecosystem.
npm is Node’s built in package manager. It has a very intuitive syntax, similar to yum, that takes less than 10 minutes to get familiar with.
Node.js is only 4 years old, but it has already found its place on IIS. Visual Studio supports Node.js development with full intellisense support of Node modules.
Being inherently asynchronous makes it very well suited to dynamic, reactive apps.
Node uses a single event loop at its core to service incoming requests. The event loop runs on a single thread that is completely isolated from the other threads in the process. Its only function is to route (emit) incoming events over to listeners and process callbacks. Event context is maintained by means of a small data structure on the same event loop thread. This is more efficient on the CPU than assigning a pooled thread to process an incoming event, which would incur a cost of switching thread contexts.
Bill Scott of PayPal describes their rationale to moving to Node in this video
PayPal’s performance benchmarks comparing Java and Node deployments reveals Node scales better and uses less resources than it’s Java equivalent.
Read the full article on the PayPal Engineering blog, I find this statement sums it up pretty well – “our initial performance results were using a single core for the node.js application compared to five cores in Java”
One of the primary benefits of moving to Node.js is it’s possible to work with a single language across the wire, on the browser and on the server.
One of the lesser known features of Node is that its possible to write Node modules in C++.
Visual Studio (and the lesser known WebMatrix) already supports Node. Hopefully, Visual Studio will include project templates and debugging support for native C++ Node add-ons in the near future.
The Internet of Things will need a server running on the “things”, and I see Node as a key enabler of smart, connected devices.
Node’s lightweight, resource friendly and event driven nature make it an attractive choice for use on IoT devices. I’ve even got Node running on my Raspberry Pi.
If you’ve used Node.js, get in touch! I am interested in hearing about it.
Thanks for reading.