How does a Node.js "server" compare with Nginx or Apache servers?

I have been studying Node.js recently and came across some material on writing simple Node.js based servers. For example, the following.

var express = require("express"),
http = require("http"), app;

// Create our Express-powered HTTP server
// and have it listen on port 3000
app = express();
http.createServer(app).listen(3000);

// set up our routes
app.get("/hello", function (req, res) {
    res.send("Hello World!");
});

app.get("/goodbye", function (req, res) {
    res.send("Goodbye World!");
});

Now, although I seem to understand what's going on in the code, I am slightly confused by the terminology. When I hear the term server, I think about stuff like Apache or Nginx. I am used to thinking about them as being like a container that can hold my web applications. How does Node.js server differ from Nginx/Apache server? Isn't it true that a Node.js based server (i.e. code) can still be placed within something like Nginx to run? So why are both called "servers"?

It's a server, yes.

A node.js web application is a full-fledged web server just like Nginx or Apache.

You can indeed serve your node.js application without using any other web server. Just change your code to:

app = express();
http.createServer(app).listen(80); // serve HTTP directly

Indeed, some projects use node.js as the front-end load balancer for other servers (including Apache).

Note that node.js is not the only development stack to do this. Web development frameworks in Go, Java and Swift also do this.

Why?

In the beginning was the CGI. CGI was fine and worked OK. Apache would get a request, find that the url needs to execute a CGI app, execute that CGI app and pass data as environment variables, read the stdout and serve the data back to the browser.

The problem is that it is slow. It's OK when the CGI app was a small statically compiled C program but a group of small statically compiled C programs became hard to maintain. So people started writing in scripting languages. Then that became hard to maintain and people started developing object oriented MVC frameworks. Now we started having trouble - EVERY REQUEST must compile all those classes and create all those objects just to serve some HTML, even if there's nothing dynamic to serve (because the framework needs to figure out that there's nothing dynamic to serve).

What if we don't need to create all those objects every request?

That was what people thought. And from trying to solve that problem came several strategies. One of the earliest was to embed interpreters directly in web servers like mod_php in Apache. Compiled classes and objects can be stored in global variables and therefore cached. Another strategy was to do pre-compilation. And yet another strategy was to run the application as a regular server process and talk with the web server using a custom protocol like FastCGI.

Then some developers started simply using HTTP as their app->server protocol. In effect, the app is also an HTTP server. The advantage of this is that you don't need to implement any new, possibly buggy, possibly not tested protocol and you can debug your app directly using a web browser (or also commonly, curl). And you don't need a modified web server to support your app, just any web server that can do reverse proxying or redirects.

Why use Apache/Nginx?

When you serve a node.js app note that you are the author of your own web server. Any potential bug in your app is a directly exploitable bug on the internet. Some people are (justifiably) not comfortable with this.

Adding a layer of Apache or Nginx in front of your node.js app means you have a battle-tested, security-hardened piece of software on the live internet as an interface to your app. It adds a tiny bit of latency (the reverse proxying) but most consider it worth it.

This used to be the standard advice in the early days of node.js. But these days there are also sites and web services that exposes node.js directly to the internet. The http.Server module is now fairly well battle-tested on the internet to be trusted.

NodeJs creates its own server. As you can see, terminology is quite clear:

http.createServer(app).listen(3000);

Create a server and listen for http requests on port 3000.

We used nginx in one of our project, but it was more like a loadbalancer for multiple nodejs instances.

Lets say you have two nodejs instances running on port 3000 and 3001, Now you can still use nginx as a server to listen your actual http calls on port 80, and may want to redirect your request to nodejs server or maybe some other server, more like a loadbalancer. So you can still use whatever nginx provides with nodejs.

A good question already asked here.

Assume there is a hotel named Apache Hotel which has a waiter for each customer.

As soon as the customer orders a salad, the waiter goes to the chef and tells him. While the chef prepares the food, the waiter waits. Here,

Chef => File System,

Waiter => Thread,

Customer => Event.

Even when the customer orders water the waiter brings only after serving the salad. The waiter keeps on waiting until the salad is prepared by the chef. This state is referred as blocking state. Even if the hotel grows each customer should have different waiters to serve. This increases the blocking of threads(waiters).

Now, coming to Node Hotel there is only one waiter for all the customers. If first customer orders soup the waiter tells the chef and goes to second customer. After the food is ready the waiter delivers to the customer. Here the customer will not wait. This state is referred as Non-Blocking state. The single waiter(Thread) servers all the customer and makes them happy.

Thus, Node which is a single threaded application is very fast.