Then this post might be interesting for you. We are going to explore the core ideas behind Node.Js and its surrounding components. I'm no expert when it comes to running JavaScript on the back-end. But I learn as I do my research, and maybe you can comment additional information in the comments!

Node.Js was initially created by Ryan Dahl in 2009. The common misconception is that many developers think Node.js is the first-ever server-side runtime for JavaScript, but it is not. Netscape had the first server-side runtime, titled "LiveWire," which was created in 1996. Yes, not kidding 1996!

What can Node.js do? It can modify server files (create, delete, read, open/close), dynamic page generation, get form data (just like PHP does), and perform operations on your database.

We already had server-side technologies before Node, so why did Dahl decide to create this runtime? Because the most popular web server at the time, "Apache HTTP Server," was not enough for what he was trying to do. He wanted to create 10 thousand+ connections simultaneously, and he couldn't achieve that with Apache. So, he decided to create his own web server. He ended up making Node.js a runtime that supports asynchronous programming instead of the traditional synchronous ones. So, no more starting the execution from top to bottom!

Let's continue with an interesting incident that occurred back in 2016. There was this Turkish programmer living in Ontario who was writing open-source code and had many npm (the package manager) packages on GitHub. One of them was very popular, left-pad.

Lots and lots of software used this tiny little code that he published, and it was really a very simple function and nothing else. But you know, people love open-source and typing npm on the command line. So, one time he was working on a new project, he decided to name it "kik," but it had nothing to do with the famous company "Kik." Even if that was the case, the company asked him to rename his npm project to something else, but he rejected, continued to insist, things got crazy, npm got in talks with Kik the company, they ended up agreeing and renaming this programmer's project to something else. He got mad, told npm that he won't write open-source on their platform ever again, deleted all his previous open-source code from GitHub, and started his protest.

It all seems normal till now, but the end result wasn't very heartwarming for big software companies. Because lots of software used this tiny little open-source function written by this open-source developer in Ontario, and they just forgot about it. So when he deleted his code, the updates to huge software projects around the world were not getting done and facing missing package errors.

Npm, the company, decided to restore the code even though the original creator deleted it as a protest. Npm said that they had to restore it because it affected people all around the world and it was the right thing to do, etc. Who was right? I don't know; I'm not a lawyer. But I think this story tells a lot about how to build your software.

I added this story here because I think it is an important part of Node.js history. It tells a lot about the 'what could go wrong' situations and what to look out for.

Now, let's talk about the architecture:

Node.Js uses event-driven programming for web servers, which enables fast working JavaScript servers. It allows scaling without threading and uses callbacks to know if a task is complete or not. It was built on Google's V8 JavaScript engine. Node.js operates on a single-thread event loop, which means it is not like traditional multi-threaded web application technologies such as ASP.NET, Spring, JSP, Ajax, and so on.

So what is this 'single-thread event loop' actually? Does it mean it takes each request one by one and makes the user wait in line for hours until all the requests are satisfied? No, it is a bit different. Node.js executes JavaScript single-threadedly, but the event loop is multi-threaded (written in C++). There is a misconception with this single-threaded expression because it doesn't really mean what you think it means. It means that all JavaScript, V8, and the event loop run in a single thread. This doesn't mean EVERYTHING runs in a single thread, blowing up your servers, and then you calling the fire department and yelling at customer support in tears. Instead, because a good part of this technology is written in C++, which definitely has access to multi-threading, everything depends on what you are running and where you are running it.

If you are running a JavaScript method that is synchronous, some C++ code will start running on the main thread. If your method is asynchronous, it can either run on the main thread or sometimes it does not. If the methods are asynchronous, you can expect them to run simultaneously in separate threads, and if it is synchronous, you can expect it to run on the main thread.

So, no, Node.js doesn't run everything on a single thread; it still uses multi-threading. It still has a "thread pool." But this pool isn't used evenly for every request. If the user requests computational power greater than amount x and the thread pool doesn't have much left, the other requests should wait until the pool is free again. So basically, you wait in a queue. The system uses a never-ending loop; this loop waits for requests, takes them, assigns them to available threads, one by one.

Sources:
https://www.youtube.com/watch?v=zphcsoSJMvM
https://en.wikipedia.org/wiki/Node.js
https://www.section.io/engineering-education/history-of-nodejs/
https://qz.com/646467/how-one-programmer-broke-the-internet-by-deleting-a-tiny-piece-of-code
https://blog.risingstack.com/history-of-node-js/
https://dev.to/macargnelutti/server-side-javascript-a-decade-before-node-js-with-netscape-livewire-l72