Node.js — How is it different?
Hi folks, I have been interviewing full stack developers for quite some time now, and I ask this one question to almost every MEAN/MERN stack dev — “HOW is Node.js different from the others?” I found there are very few people out there who could answer it properly. Yes the question is broad indeed and there can be many perspectives to it, but in the end, they all must fall in the same bucket of— SINGLE THREADED and NON BLOCKING RUN-TIME ENVIRONMENT. Most are unaware, some just knows the answer but don’t know “WHY” its called so. When this topic is discussed among non JS developers, they often asks:
. How Node.js being SINGLE Threaded is so fast?
. If this single threaded setup can work as fast and efficient as those other multi-threaded solutions provided by Java, Python,C# and other big guys?
. So when does Node.js fails?
Lets take an example of — a simple request-response app which requires database communication as part of fulfillment. I will try to throw as much light as I can on this topic.
Traditional way of Request-Response handling
Point to note here — is the “Delay” between requests. A new request cannot start processing until the response from the previous request is received.
i.e. For Request 2 to start processing, it must wait for time(Delay) Request 1 finishes processing.
Things are synchronous here (one after another). The “Delay” needs to be taken care of, to make it robust. Hence to handle huge amount of simultaneous requests you need to spawn new THREADs to serve each request independently. In this process you need to allocate memory for each of these threads being spawned which is not very cheap when you have to create thousands of them but hey, it solves our “Delay” problem.
So when the threads are at work. It will look like this.
Request 1 -> spawn new thread -> query the database -> Response 1
Request 2 -> spawn new thread -> query the database -> Response 2
Request 3 -> spawn new thread -> query the database -> Response 3
...
Request n -> spawn new thread -> query the database -> Response n
Independent and robust (but not very efficient in this case of example).
JavaScript, Node.js way of Request-Response handling.
Point to note here — is there is NO “Delay” between requests.
What’s happening here is Request 2 doesn’t wait for Request 1 to finish processing. Every time a Request n is hit, it starts processing without any waiting and the Response n is sent almost the same moment the database processing is done. As there is 0% CPU involved waiting for database to respond, it can read next request and send for processing.
Both the approaches returns the data in approximately the same time, as there is no CPU processing involved, majorly depending on the time taken by the database to resolve the query.
The main advantage here is we do not have to spawn new threads to handle the requests, thereby eliminating the complexity, time and memory involved.
JavaScript is an Event-Driven Programming Language as we know. Hence Node uses Event-Driven architecture — That means anything that happens in Node.js is through an event.
So when a node server is started, it initializes the variables, requires modules and registers callbacks for events. It is the Event loop that continuously listens for events and executes their respective registered callbacks (handlers). This happens one at a time — it is not parallel. Parallelism happens in a separate worker threads for lower lever operations, i.e. say we made an API request that involves database processing (like our example), so its our Node’s single thread that listened to the API request event, triggers its attached handler, (in where database processing request resides) now the adapter that is responsible for making the communication happen with the database and the processing to be done with the database queries - actually spawns a new thread (in case if its already busy handling request from some other event through a thread — multithreaded) to handle this request.
In brief-
Even though the Node.js (or rather at JavaScript core) application uses single thread to execute the code, but under the hood it makes use of multi-thread behavior of another process -in our case the database .
When Node.js falls behind?
Node’s underlying architecture implementation fails when some CPU intensive work is involved. By CPU intensive I mean works like Image processing, audio encoding, media conversions, etc. All these jobs involves huge CPU computations and almost no I/O. Hence when the event (which involves as such work) handler is fired, it keeps the the event loop busy until the time the CPU processing is finished, it halts all other events in the process. This case is where C++, Java, Python and all other excels coz their underlying architecture makes use of multiple threads to handle concurrency at their core.
