Stop fighting Node.js in the enterprise
But why would I implement some other server…
Second, Node.js is NOT limited to HTTP/S. Node.js has support for TCP and UDP. Focusing on HTTP/S takes away from the raw power of Node.js. People have built some crazy things like DNS and SMTP servers. This is important because I don’t recall anyone implementing a DNS server in IIS. This level of flexibility creates so many additional options that the current enterprise server selections just cannot match.
Because you don’t get compile-time checks…
Because you shouldn’t do anything really complicated with it…
Because of some single-threaded issue…
This argument is complicated because it is nowhere near as technically simple to argue as it sounds. Under the covers, Node.js manages its own threads for I/O for each process. There are so many weird issues here that it becomes difficult to find a place to start without saying something incorrect. Let’s take that sentence piece by piece.
“Under the covers,” Node.js is an open-source application written in C++. Because Node.js is written as regular program, it can do anything else a program can do. The fact that Node.js can run scripts is irrelevant to the underlying architecture of Node.js itself.
Even with all of those caveats it gets more complicated because Node.js is extensible and modules can include native code. Native code can generate threads. There are already modules that generate background and worker threads to perform their own functionality, and several modules that provide threading as their primary purpose.
With all of that said, it doesn’t matter. The fundamental problem with these arguments is that Node.js as a platform is designed around asynchronous I/O and not threading. Those concepts are similar, but completely different. In essence, it doesn’t matter if Node.js is multithreaded. Multiple threads are useful to complete multiple long-running tasks simultaneously. The problem is that long-running tasks in modern web applications are not really long-running, but instead they are blocked by long-running calls external to the actual executing thread. Most of the time spent during a normal request to a modern web application is spent waiting for a database call, REST API request, or file operation to complete. Asynchronous I/O takes a different approach by issuing an external call and moving on to the next available operation, or in the case of a web server, the next available request. When the call completes, it gets thrown into the event loop just like anything else. When it makes it to the front of the queue, the function to run upon call completion is executed without the actual thread ever waiting. This allows a single thread to handle many more request than a traditional multithreaded approach. Additionally the memory required for a closure-based context is much less than a traditional reusable pooled thread approach. The asynchronous I/O approach is so compelling that the async and await keywords were introduced into C# as part of .NET 4.5 and asynchronous controllers were introduced in ASP.NET MVC 4.
This argument usually comes from a lack of understanding of asynchronous I/O. Node.js can scale as much as necessary with the previously mentioned asynchronous I/O model, clustering to scale across CPU cores, and cloud-based elastic computing. For example, check out Uber’s results when they transitioned to Node.js from a LAMP stack.
But there aren’t any serious implementations out there…
Microsoft and Amazon both support Node.js with Microsoft being a major contributor to Node.js since 2011. Azure Web Sites and AWS Beanstalk both provide simple methods for deploying Node.js applications into the cloud. There is no way to know what amazing things are coming, but there are several serious projects already out there.
Doctape is using Node.js for API requests as well as also media streaming and conversion. Scrollback uses Node.js for their real-time messaging infrastructure. FrisB converted over to Node.js for scalability improvements for their WebRTC infrastructure. Twelephone is using Node.js for their Sykpe-alternative. Voxer uses Node.js for their messaging infrastructure. PINT’s entire CMS system is built on Node.js. Fidelizoo uses Node.js for their digital loyalty card management system. Transloadit uses Node.js to handle millions of file upload and conversion requests per month. ZingChart uses Node.js for server-based chart rendering. Caliper uses Node.js for trace requests for their analytics platform. Klout is also built on Node.js.
Fine, but nobody I’ve actually heard of is using it…
There are actually plenty of major players already using Node.js. eBay is using Node.js for the ql.io platform. MySpace is now a Node.js application. The mobile version of the New York Times is a Node.js application. LinkedIn uses Node.js for their mobile application stack. PayPal is moving their entire application platform from Java to Node.js. PayPal, by the way, is at the time of this post the 17th most visited site in America and the 41st most visited site in the world.
But… But… But…
Check out these statistics showing the growth of Node.js websites over the last 6 months as well as the traffic those sites are handling. Sure that number is a very small percentage, but growing by 241% in 1 year is impressive either way.
Node.js is only going to get bigger. It is not a fad. Yes it has faults, but it is ready for primetime right now. My next posts will cover some of those faults