Similarities between the Architectures of Node.js and NginX
Photo by Diego Jock on Unsplash

Similarities between the Architectures of Node.js and NginX

In this article, I'll try to explain the similarities between the Architectures of NginX and Node.js, in the easiest way possible. I won't be talking about the whole Architecture of Node.js or NginX, but only the parts that are common between them. So, if you already know the Architecture of any one of them, you'll understand the other. Let's start by understanding what exactly are NginX and Node.js, obviously if you are here then you must know what these are, but let's not forget about the newcomers.

Basic Understanding

NginX, is a web server that can also be used as a reverse proxy, load balancer, mail proxy and HTTP cache.

Node.js is a Javascript run-time environment that runs on the Chrome V8 Engine.

You won't find any similarities if you compare the above definitions, but they are similar in the work that they do. Let me explains :). NginX is a web server, but besides being a web server, it can also work as a reverse proxy, load balancer, mail proxy and HTTP cache. If you don't know what a reverse proxy, load balancer, etc. mean, don't worry, it's not important at this moment, just know that all those things are similar to a web server, but they do things that are some what more complicated than simply querying the database and returning the response for a request from the client.

Now let's talk about Node.js. It is basically a piece of Software using which you can run Javascript code, outside the browser. Before Node.js was created, Javascript could only be executed in a Web Browser. Node.js uses the Chrome's V8 Engine(V8 Engine is the Component or the piece of Software that Chrome uses to run Javascript) to execute Javascript outside a browser. So, with Node.js we can write programs that can do anything just like what a program written in C++ or Python would do. Node.js is mainly used to create Web Servers, because of it's Non-Blocking IO Architecture. Node.js can be installed on a Web Server and then we can write some code that would handle the incoming requests, query the database and return the response. Node.js natively provides some APIs that make this process of writing code for handling HTTP requests a lot easier. And yes! We can also create a load balancer, reverse proxy, etc. with Node.js, but that would require us to write a lot of code to handle all that functionality, whereas NginX has all of that inbuilt.

Similarities

Well now that you have an idea of what Node.js and NginX is, let's start with the topic for which I am writing this article.

NginX and Node.js have quite a similar Architecture. Both of them are different from the multi-threaded Web Servers that uses one thread per connection, to handle requests.

  1. NginX has a Event-Driven Non-Blocking Architecture just like are beloved Node.js. In NginX an event occurs when a new connection request is made or when a previously connected client makes a new request which is exactly what events Node.js listens for on the server object returned by the createServer function in Node.js(server.on("listen").
  2. NginX has a Master or Main Process along with a couple of worker processes and helper processes. The Main Process has only a limited number of tasks to perform like reading Configuration, binding to ports and creating the Worker Threads. The Worker Processes are the ones that do all the work. A Worker Thread in NginX is similar to the "Main Thread" also known as the "Event Loop" in Node.js. The Worker Thread works just like the Event Loop, picking a task, processing it, returning the response and then moving onto the next task. The main difference here is that instead of having only one Thread to process the tasks in Node.js, NginX has more than one(generally equal to the number of CPU cores) worker threads.
  3. Node.js does not have a real queue for it's Event Loop(It does have a real queue for the thread pool), instead it uses IO Multiplexing Mechanisms like kqueue, event ports and epoll provided by different Operating Systems. It primarily uses the libuv library for asynchronous operations. It uses the file descriptors or socket descriptors to listen for read, write and other operations, which those descriptors represent. NginX also uses the above mentioned IO Multiplexing Mechanisms, for it's Worker Processes, to listen for events on the Connection and Listen Sockets. These help both NginX and Node.js to perform asynchronous tasks.
  4. Node.js has a thread pool to handle the Blocking or CPU intensive tasks that cannot be handled by the Event Loop. The Worker Threads of NginX also have some Auxiliary Threads that perform the CPU intensive task that the Worker Processes cannot preform since that would block that thread.

No alt text provided for this image

Note: I am not sure if the Worker Processes do have some Auxiliary Threads or not(Mentioned in Point 4). Because as per the representation(the above image) on the official NginX site, there was mentioned something about Auxiliary threads to handle Blocking IO operations, but I couldn't find any article related to this. I still wanted to put this point in this article, in case it does prove to be right. So, it might be that NginX does not have any such Auxiliary threads and the worker threads themselves do all the task. Do, let me know in the comments if I'm wrong :)

Having a limited number of Threads to process the requests reduces the CPU cycles that Node.js and NginX need, since they do not have to create and destroy threads when they complete with one request or start with a new request.(They use the same threads for all the connections).

Processing a request requires a small amount of data, the Socket or File Descriptor and the task that it needs to perform, and creating a whole new thread for such a small task does not seem scalable and also wastes a lot of resources.

So, these were the similarities that I could find between NginX and Node.js, if you guys know something that I might have missed, then do let me know in the Comments Section. That was all from my side. I hope that you learnt some new things from this article :)


Very Informative article. Thanks for sharing

Like
Reply

Prashant Pandey Great article. Thank you so much for that! I think I have a question. I got the idea of the "Nginx Main Process" which delegates the requests to "Workers". Let's say that we have a "Main Process" (which is single-threaded) and only 1 worker, for the sake of simplicity. My question would be: Is this "worker" multithreaded? Otherwise, I don't think the worker will be able to handle 100 requests concurrently... it will be blocked, since computer can only execute 1 instruction at the time. Is it correct to affirm that "Nginx Workers" are multithreaded? If not, how do they manage 100 requests concurrently, since computer can only execute 1 instruction at the time? Thank you so much for your help!

To view or add a comment, sign in

More articles by Prashant Pandey

  • Cross Origin Resource Sharing

    Getting CORS error in the Developer Console is something that every Frontend Developer has faced when he first started…

    2 Comments
  • gRPC vs REST

    Every developer must have heard about REST in his/her life. REST stands for REpresentational State Transfer.

  • What is QUIC and is it really quick?

    If you have never heard of the word QUIC and you are a developer, whose work is somehow related to the fascinating…

    4 Comments
  • What exactly are UUIDs and how are they so Unique?

    If you have ever worked with any kind of database, be it SQL or NoSQL, in your life, then you must have come across…

    1 Comment
  • How http became the https that we know today?

    The only difference that one can notice between http and https by just looking at the words is the letter s, but this…

Explore content categories