“Node-ing” Is Half the Battle

6/9/2016 3:33:10 PM

0

Like most things in the tech world you can just start using Node.js without knowing much about it. This article helps you to make the decision and gives you the information necessary to choose the right tool for the right job.

What is/isn’t Node.js?
Node.js is not a framework. It's not like AngularJS, JQuery or other server-side frameworks. Node.js is in fact a server like IIS and Apache. Additionally, Node.js is platform independent and can run on Windows or Linux servers. 
Node.js is popularly used as a web server and is quite good at that task - however, Node.js is not exclusively a web server. Node.js can be configured to accept connections from various sources in various fashions. For example, an endpoint for a photo booth that can email you pictures of your trip to the fair. It can also accept no connections and simply perform a task such as calculate all the digits of PI - though it is not optimized for intense CPU activity given its single main thread (more about this later). 
Since the most common use for Node.js IS as a webserver, let's talk about that.


The Good
Node.js is really fast - as in it can serve content extremely quickly with high concurrency. Since it uses JavaScript, the same functions you use for client side validation, parsing, and heavy lifting you can directly paste into your server side code. Node.js is made in C (C is inherently fast), it is good at handling streaming of large files, and good at making multiple concurrent external API calls (due to its event driven nature).


The Bad
Node cannot use multiple CPU cores by default. There are ways to launch multiple load-balanced Node.js instances but there are no exposed threading libraries for the Node.js developer. As a result of no threading API, apps that require CPU intensive tasks are therefore NOT recommended in Node.js. In fact, if there is one take away from this article it’s this, “Do not choose Node.js if your app must perform CPU intense operations (like reporting or machine learning).
In Node.js database manipulation is a bit more difficult as JavaScript is not generally used to connect directly to a database. Event based callbacks are great until the nested callbacks become crazy and unmanageable. Node-cluster (the built in load-balancing solution for Node.js) does not load balance well and in benchmarks the master process gets 50% of all load - other CPUs sharing the other 50%.


The Ugly
The first CON I ever heard about Node.js is it's "single threaded". So naturally I said, "That's dumb there goes any actual large scale or enterprise use" and moved on. That, however, is a filthy lie - or well, maybe half a lie.
This is how Node.js actually works – Node.js has a Listener thread which listens for input and does the main body of the work (much like a GUI thread). When the request comes and the request is long running like a file upload or other IO bound work (and this is where multi-threading comes in) it actually takes the process and dumps it into a thread pool to do the heavy lifting and immediately returns to listening. Wait what do you mean thread-pool, Node.js is single threaded! Actually, no it isn't - The listener thread is single threaded but that is an event loop popping callbacks and requests off the stack. CPU intensive tasks ARE done on this thread and the thread-pool is not directly accessible to the developer.


Node.js vs .Net
Node.js forces you into a nice efficient ASYNC programming model (pattern) by its very implementation. The mastermind behind Node.js decided that event based architecture made for a great server framework (they aren’t wrong) and thus that is what Node.js became.
While Node.js provides a great pattern - it is not a replacement for .Net. Given the level and variety of APIs exposed by the .Net framework, it can do everything that Node.js can do (in mostly the same way) assuming the same ASYNC pattern is implemented.
Some may say that the Node.js is faster than .Net however most of that is overhead caused by IIS – a standalone .Net server benchmarks similarly to Node.js in similar usages.


Making the Choice
Knowing how Node.js works and what sort of things it is good at - THAT is what allows you to choose Node.js where appropriate for enterprise level tasks. Willing and able to set up a server-side load balancer to balance multiple Node clusters? Then use Node.js. Do you have a number crunching reporting framework that outputs real-time performance data? Then node.js is not a good solution for that purpose. Do you need a file upload server that doesn't sit on your main web server? Node does that type of task well. Need a game server for a large scale multiplayer game? Node.js just might work for that.


Conclusion
All technology is meant to fix a problem. Some technology fixes many problems but before you choose the tech - make sure you understand your problem. Node.js is NOT the best for everything but it IS the best for some things!