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

javascript node.js apache nginx webserver

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"?

Isn't it true that a Node.js based server (i.e. code) will still be placed within something like Nginx to run? No, that's incorrect

technically you can run your app and have node serving it up to the client effectively filling the role of the webserver, but you're probably biting off more than you want to chew. I recently read this great article on the topic: nginx.com/blog/nginx-vs-apache-our-view

Let me clarify that when I asked for the difference between the two, I was NOT taking about apache vs nginx. I was taking about Node.js vs Nginx.

Don't let the title misguide you. If you read the article you'll understand why I said that while you can do it yourself, you may not want to...

Jonathan Lam

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.

I have read in similar SO threads that putting an Nginx or Apache layer in front of Node "takes away its non-blocking nature". Any thoughts on this?

@MrfksIV Both Nginx and Apache2 are nonblocking. In fact they implemented nonblocking long before node.js existed. Don't use Apache1

Any ideas about what architecture node-cgi uses? I have the impression that it is the classic thread based architecture (so every request gets its own thread), while I need a hosting provider with event based architecture (every request is processed on the same thread). I have no idea which hosting provider supports this kind of architecture if I don't want a cloud service, docker, etc. just something that runs nodejs, supports websockets, etc.

@inf3rno If it's CGI it's CGI so really the worst architecture for scaling as it consumes a lot of RAM. However node processes typically take only around 30MB of ram at start-up so not as bad as something like Java. CGI is not even thread based. It is process based. Each request spawns a new process (app) and sends data to the process using environment variables (yes, it's awkward by modern standards but easy if you just learned C programming on unix because you don't need to learn anything about tcp/ip or sockets)

@inf3rno For hosting one of the most popular way to run web apps support node: Heroku. There are lots of providers that also provide node.js hosting. Just google "nodejs hosting". However, even if you don't end up using it I'd encourage you to look at AWS. They give away 1 year free accounts. They provide everything from a virtual hardware where you can install any OS you want to a container runner where you can upload your docker image to run to an app runner where you you just give them your code to even running just a function where you don't even give them a complete app

Community

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.

I am actually not too focused on nginx itself. I was wondering about the difference between the node.js "server" and the other "servers" like apache or nginx. I couldn't understand how the contained (i.e. node code) could be equated to the container (i.e. apache)... But I guess this understanding was incorrect. Now, I realise that node.js code listens to port 3000 just like Apache listens to port 80.... So I guess they are similar. So it's it true to say that they are both servers that have their own strengths and weaknesses?

createServer just creates a listening port. It doesn't serve anything.

What would be the point of having nodejs use createServer to listen on a port if it's not going to serve something upon a request to that port? ... Therefore, it is one way or another by logical extension a "server", no?

@RogerF.Gay... it creates a listener on a specified port, and executes a callback function on incomming request. thats what i would say it creates a server.

@Naeem Shaikh It doesn't serve anything. Calling something that doesn't serve anything a server does not make sense.

Adil B

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.

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

Follow WeChat

Want to stay one step ahead of the latest teleworks?

相似问题

Platform

Support

Contact US