In this edition of our blog, I thought I’d take you back to the fundamentals of Node.js. If you are new to Node.js development or are looking at this “jargon” from the customer’s perspective, it will give you a better idea of what it is and what it can do.
But, it’s important to note that, it is one of the biggest advantages of adding Node to your stack.
Another notable fact is that Ryan Dahl, Node.js’ creator, wanted to make real-time websites that support push technology like the Google applications. With his creation, he provided developers with a tool that allowed them to work in the event-driven, non-blocking I/O paradigm.
In a nutshell, Node.js works best in real-time web applications that use push technology instead of web sockets. What’s the big deal? For over 20 years, developers worked with a stateless request-response paradigm but now there are web-applications that allow both the server and the client to communicate and exchange data easily.
This is remarkable when compared to the average web response paradigm, where the client must start communication.
How it Works
Node.js’ many advantages make it an essential component of the technology stacks of a large number of high-profile companies, who are dependent on the large variety of benefits that it provides. It operates under one main principle: use event-driven, non-blocking I/O to stay efficient and lightweight, even when dealing with data intensive applications that run across the required devices.
What does this mean? Node.js is a platform that was designed to fit a certain need, it’s not expected to be the be-all and end- all of the web development world.
In other words, Node isn’t recommended for use in CPU-intensive operations, doing so will nullify virtually all of its benefits. Because of its ability to handle a multitude of connections simultaneously and with high throughput (which means high scalability), Node shines when used to built fast, scalable network apps.
Unlike conventional web-serving methods where every connection generates a new thread (which takes up RAM until it is eventually maxed out), Node works on one thread and uses non-blocking I/O calls to support thousands of simultaneous connections in the event loop.
For example, if each thread has an extra 2 MB of memory and they are running on a system with 10 GB of RAM, then there should be a maximum of 5000 simultaneous connections, in addition to the cost of the context switches between the threads. The preceding is reminiscent of a typical scenario that developers must contend with when using conventional web-serving methods.
Node, on the other hand, is able to sidestep this entirely and instead reach scalability levels of over 1 million simultaneous connections.
It is also important to note that there are some pitfalls to having all client requests on one thread:
• Node’s single thread can get choked up by heavy computation and cause issues for clients because incoming requests are blocked until the computation is finished
• If an exception bubbles to the central Node.js event loop, it will cause the instance to stop and crash the program.
In order to prevent exceptions from bubbling to the core, developers must send the errors back tot the caller as callback parameters, versus throwing them like you would in other environments. Plus, there are a variety of tools and paradigms that can be used keep to track of the Node process and perform the recovery of a crashed instance if an unhandled exception happens to bubble. But, it’s important to note, you won’t be able to retrieve the users’ session
The most common of these tools is the Forever module, but if you would prefer going a different route (with using external system tools) consider upstart and monit instead.