Can we say node.js is a web server?

Question

I found that I am confusing between web framework and web server.

Apache is a web server.

Tornado is a web server written in Python.

Answer 1

I just used Node.js for the first time to create a Discord bot. My thought was "Wow, Node.js is a server? I thought it was a JS library!" Or perhaps I could have thought about it as a framework.

Is it a web server? No but you can make one with it. Is it a server? As in the software that receives queries and serves the result? Yes.

In my case, I have issued the command: node index.js

And now Node.js is waiting for requests to respond to (via my bot). It's a server, but it isn't serving web pages.

Answer 2

No it's a runtime environment... so it is not a web server yet it does not need one to run. So probably this is why it could be confusing. It can run standalone without needing any webserver because it is a runtime itself but again it is not a webserver.

Answer 3

I would classify node.js as a server framework, with packages available that can make use of it as an HTTP server, or a WebSocket server, or your own custom protocol, etc.

The reason you might put nginx in front of your node.js server is for HTTP load balancing and reverse proxying across several machines running your server application.

Answer 4

Web server is something that serves its clients through internet over protocols and Web Framework is something like which we call as compiler. It consists of all the required libraries, syntax rules, etc.

And node.js is a framework!!

Answer 5

I think the problem is that the terminology of "web server" or "web application server" is dominated by the JEE world, and products, that are not as modularized as today's Javascript world of frameworks, which in turn can be combined more or less freely.

I see no reason why a technology, that can serve complex applications over the web, should not be called a web server, or web application server!

If you combine, let's say Nuxt as a frontend, with Feathers as a backend - you'll have a backend serving a REST API and a server-side rendered UI!

Of course, you could (mis)use that to serve static content - then I'd call it a web server, or you could use it to make and serve a full application - then I'd call it a web application server.

It's the combined features or qualities that sum up to serve a purpose - right? - Features like stability, scalability and such are IMHO something that will be added to those technologies, over time. For now, they're pretty new still.

Answer 6

How I feel your pain !

Like many, I found it hard to get to the essence of Node.js because most people only write/talk about the part of Node that they find useful - and the part they find interesting is usually a secondary benefit of Node rather than its primary purpose. I must say that I think it's mad for people to say that Node is just a JavaScript runtime. Node's use of JavaScript - and its selection of the V8 runtime - are simply means to an end, the best tools for the problem that Node's developers wanted to solve.

Node's primary purpose was to make the management of user events in a web app more efficient. So Node is overwhelmingly used on the back end of a web app. Event management demands that something is listening at the server machine for these user events. So a http server must be set up to route each event to its appropriate handler script. Node provides a framework for quickly setting up a server to listen on a dedicated port for user requests. Node uses JavaScript for event handling because JavaScript has callback functions: this allows one task to be suspended until the result of a dependent task is returned. Not many other languages have this feature and those that do may not have an interpreter as effficient as Google's V8 runtime. Most web developers know JavaScript so there's no additional language learning with Node. What's more, having callback functions allows the putting of all user tasks on a single thread without having explicit blocking applied to tasks demanding access to the database or file system. And this is what leads to the superior executional efficiency of Node under heavy concurrent use - the primary purpose for its development.

To help Node users quickly write back end code, Node's developers also organized both a built-in JS library for routine tasks (e.g. matters related to HTTP requests, string (de)coding, streams etc) and the NPM (Node Package Manager) repositary: this is an open source, user-maintained set of script packages for various standard and custom functions. All Node projects allow importation of NPM packages into a project via the established npm install command.

User requests handled via Node will be things needed by the web app like authentication, database querying, content management (Strapi CMS), etc. All these will be sent to the Node port. (Where analysis of data got from a database is takes a lot of CPU time, this type of process is best put on a separate thread so it doesn't slow simpler user requests.) Other types of user request, e.g. to load another webpage, download CSS/JS/image files, etc, will continue to be sent by the browser to the default port(s) on the server machine where the web server program (Apache, NGinx, etc) will handle them.

So, in practice, Node is principally a framework for rapid server-creation and event-handling but one that replaces only some of the functions of the web server program.

Other non-backend uses of Node simply exploit one or other of its features, e.g. the V8 engine. For example, the frontend build tools Grunt and Gulp use Node.js to process a build script that can be coded to convert SASS to CSS, minify CSS/JS files, optimize image size/loading, etc. But this sort of work is really just by-product use of Node, not its principal use which is for making efficient backend processes for web applications.