I am confused as to why when building a node/express application I dont need to use another web server but when working with Java or Spring or a python backend usually a webserver like nginx or apache is used. I am getting confused as to what Apache and nginx do, don't they just handle HTTP requests just like we do in node or express? But then in Spring there are controllers that handle the requests so why do we need to have JBoss or Apache running?
In the old times there was a strict separation between the "application" and the "application server"/"web server". Application servers (like JBoss) provided the configuration of the resources (connections to DB for example), etc. to the application deployed on them. Web servers (like Apache) provided the configuration for possibly multiple web applications hosted on them.
Currently, in the era of self-hosted apps (which means: apps that contains embedded HTTP server) you often don't need a separate webserver. But tools like Nginx are still used for example as load-balancers, etc. Application servers (JBoss, etc.) are not often used nowadays, because of the embedded HTTP servers that you're able to configure without asking Ops-people to do it for you - it's quicker and more convenient.
If you are writing a NodeJS application then you don't "need" another server, except maybe when you are scaling a production ready deployment
The simple answer is that express, Apache, nginx and JBoss are all web server. Since all of these are web servers they each can pretty much do the work of each other. However, each of them have strengths and weaknesses which is why often times they can work together. For example a common practice is to place an express server behind nginx to let nginx handle load balancing, static assets and SSL termination which nginx is very good at but maybe let API and websocket connections fall through to the express server which is what express is typically good at.
A developer may pick Apache if they are working with PHP because the integration is so good but pick JBoss if they are working with Java EE.
I would like to gather some metrics about usage for an Electron-based cross-platform desktop app. This would consist of basic information on the user's environment (OS, screen size, etc) as well as the ability to track usage, for example track how many times the app is opened or specific actions within the app.
These metrics should be sent to an analytics server, so they can be viewed in aggregate. Ideally I could host the server-side component myself, but would certainly consider a solution hosted by a third party.
There are various analytics solutions for the web (Google Analytics, Piwik), and for mobile apps, as well as solutions for Node.js server-side apps. Is it feasible to adapt one of these solutions for desktop Electron-based apps? How? Or are there any good analytics solutions specifically designed for use with desktop apps which work with Electron / javascript?
Unlike a typical webpage, the user might be using the app offline, so offline actions should be recorded, queued, and sent later when the user comes online. A desktop app is typically loading pages from the file system, not HTTP, so the solution needs to be able to cope with that.
Unlike a Node.js server-side application, there could be a large number of clients rather than just a single (or a few) server instances. Analytics for a desktop app would be user-centric, whereas a server-side Node.js app might not be.
Ease of setup is also a big factor - an ideal solution would just have a few lines of configuration to gather basic metrics, then could be extended as necessary with custom actions/events.
The easiest thing will be to use Google Analytics or a similar offering.
For most you'll have two major issues to solve over hosting on a website:
Electron does not store cookies or state between runs. You have to store this manually
Most analytics libraries ignore file: urls so that they only get hits from the internet
Use an existing library and most of these issues will already be solved for you.
After a couple hours of searching top lists of free "web servers" and "web frameworks" on google, I realized I'm not sure what I'm looking at.
Let's take a couple of example softwares I have come across :
IIS
Apache HTTP server
Apache Tomcat
Socket.io
Node.js
Django
Questions :
Do all these work on the same scope/do the same thing?
If not, what is absolutely necessary to have my "helloworld.html" acessible from anywhere with internet? Let's consider I already have a dedicated server and a domain
Also if not, how do these work together/compliment eachother?
Each of this software has a different description on their website for what it does, what it is, who should use it, it really gets confusing when you're trying to find what is "fresh", what the cool kids are using
IIS and Apache are web servers that support a variety of different technologies for plugging code into the web servers. So, if you were using one of these web servers, you would also use some other framework and language runtime to plug into them.
Apache Tomcat is a Java-based server framework for web applications. From the wikipedia page: "Apache Tomcat, often referred to as Tomcat, is an open-source Java Servlet Container developed by the Apache Software Foundation (ASF). Tomcat implements several Java EE specifications including Java Servlet, JavaServer Pages (JSP), Java EL, and WebSocket, and provides a "pure Java" HTTP web server environment in which Java code can run." It may be used independently of the Apache Web Server. The "Apache" in the name has to do with it being part of the Apache open-source organization. So, if you want to program your server in Java, this is one of your options.
node.js is a Javascript-based framework that is both a framework and it's own web server. So, if you want to program your web server in Javascript, this is your main option. There are additional frameworks you might use with node.js such as Express to make programming your web server simpler.
Django is a python-based framework. If you want to program your web server in Python, this is one of your choices.
socket.io is really not like any of the others. socket.io is a layer on top of webSockets that gives you a whole bunch of additional features over webSockets. This would run in whatever server-side language and framework you were already using and you would have to select a socket.io library that was compatible with your server technology. You can see a list of features that socket.io adds on top of a webSocket here: Moving from socket.io to raw websockets?. webSockets themselves are used for continuous communication between server and client (more efficient than repeated Ajax calls) and for push notification from server to client.
So, if you were looking to select a technology from scratch, there are a number of different ways you could start your selection process.
If you have a preferred language (Java, Python, Javascript, Ruby, C#, etc...) you either know already or want to learn, then you can look at the frameworks that support your language and start there. The framework will indicate whether you need a companion web server or whether than is already part of the framework.
If you have an existing hosting company that you want to use, you may need to understand which technologies they support so you don't select something that would require you to change hosting companies. Not all hosting companies support all technologies and some are better specialists in some technologies.
If you have specific 3rd party code or libraries you want to use, you may want to investigate which languages/frameworks it can more easily be used with.
What is fresh and what the cool kids are using changes pretty regularly. I would suggest that's a crummy criteria. What makes more sense is to understand which technologies and frameworks are doing well with accelerating growth and a rich development community behind them vs. which ones may be falling out of favor. I haven't myself done any sort of overall survey to offer any sort of list of what's on the upswing and doing well vs. what is more stagnant.
I'm personally partial to node.js and the huge NPM library of open-source and compatible code you can draw from and the ability to use one language for both front-end and back-end. It is certainly one of the choices that is growing rapidly and has a vibrant development community behind it. But, it is not the only choice that would meet those qualifications.
Can I use node.js server as a web server?
Such as I will run aspx sites or wcf service in node.js server instead
of IIS? Can I do it without IIS?
There are several alternatives to IIS for hosting ASP.NET applications such as:
IIS Express
Apache (Mono)
Cassini (not actively developped)
Kayak Project (not actively developped)
C# WebServer (not actively developped)
Abyss (not actively developped)
There are probably others, but generally most of them aren't actively developed.
Node.js is a little different. It is a platform built on Chrome's JavaScript runtime for easily building fast, scalable network applications. It fetures a event-driven, non-blocking I/O model that makes it lightweight and efficient, perfect for data-intensive real-time applications that run across distributed devices. It can still act as a web server and serve content. Node applications, to my knowledge, are written in JavaScript.
With this said:
Node.js can run on IIS, that's different from .NET running on Node.js
ASP.NET websites cannot run on Node.js
ASP.NET projects can benefit from using Node.js for some of its operations
ASP.NET has its own technology similar to Node.js and Socket.io called SignalR
TLDR - No, you can't.
These are different technologies, taken from Node.js website:
Node.js® is a platform built on Chrome's JavaScript runtime for easily
building fast, scalable network applications. Node.js uses an
event-driven, non-blocking I/O model that makes it lightweight and
efficient, perfect for data-intensive real-time applications that run
across distributed devices.
It is feasible to develop an aspnx interpreter in javascript, but makes absolutely no sense to implement one programming language in another programming language.
There must be a reason of this question asked, you could instead tell us why do you desire to have Nodejs to become an aspx server, there might be more elegant solution.
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.
Nginx is a web server written in C
Zend is a web framework in php
Flask/Bottle is a web framework in Python
RoR is a web framework written in Ruby
Express is a web framework written in JS under Node.JS
Can we say node.js is a web server??? I am so confused between web server/ framework.
If somehow node.js is kind of webserver, not webframework (Express does), why do we need to put the whole node.js on top of Nginx server in useful practice??
Question on SO
Who can help???
Kit
Web server
Web server can refer to either the hardware (the computer) or the
software (the computer application) that helps to deliver content that
can be accessed through the Internet.1
The primary function of a web server is to deliver web pages on the
request to clients. This means delivery of HTML documents and any
additional content that may be included by a document, such as images,
style sheets and scripts.
A web server is the basic to delivering requests/pagess to the clients/user on the internet
Web framework
A web application framework is a software framework that is designed
to support the development of dynamic websites, web applications and
web services. The framework aims to alleviate the overhead associated
with common activities performed in Web development. For example, many
frameworks provide libraries for database access, templating
frameworks and session management, and they often promote code reuse.
A web framework uses a webserver to deliver the requests to client, but it is not the web server.
Node.js
Node.js is a platform built on Chrome's JavaScript runtime for easily
building fast, scalable network applications. Node.js uses an
event-driven, non-blocking I/O model that makes it lightweight and
efficient, perfect for data-intensive real-time applications that run
across distributed devices.
But then again you can also create CLI apps so I think you should see it more as a platform to write javascript programs to run on your server(computer) using Javascript programming language instead of just in the browser as in the beginning. I think you could see it as Javascript++ ??
You can also write web server with node.js as you can see on the front page of node.js. In the beginning Ryan said you could put Nginx in front of node.js because of the stabilty of the project. The project was and still is pretty young. Nginx is a proven web server that will keep on running while node.js can crash. Then again a lot of user just use node.js for that.
I would say Node.js is a Runtime Environment or a Runtime Engine.
Probably the best definition I have found so far comes from an article by Rob Gravelle entitled "An Intro to Node.js":
Node.js is part runtime environment and part library for building network applications using server-side JavaScript. It uses Chrome's JavaScript runtime engine to execute JS code directly without the need for the browser sandbox.
Also the PCMAG.COM Encyclopedia provides the following definition of "runtime engine":
Software that certain applications depend on to run in the computer. The runtime engine must be running in the computer in order for the application to execute. It provides common routines and functions that the applications require, and it typically converts the program, which is in an interim, intermediate language, into machine language.
Also the Wikipedia article entitled "Run-time system" declares:
A run-time system (also called runtime system, runtime environment, or just runtime) implements the basic behavior of a computer language, whether the language is a compiled language, interpreted language, embedded domain-specific language, or is invoked via an API as is pthreads.
... A run-time system may implement behavior of tasks such as drawing text on the screen or making an Internet connection. It also typically acts as an abstraction layer that hides the complexity or variations in the services offered by the operating system.
Well, are there any runtime environments (or even software platforms) like Node.js out there? I guess JRE is a good example of such an environment. Node.js and JRE - they have many in common. They all have (a kind of) virtual machine, a class library and a framework to implement many types of applications, including CLI ones.
So, getting back to your question, can we say that Node.js is a web server? Let's change "Node.js" for "JRE" and answer if JRE is a web server. The answer is no.
All that we can say is that Node.js is a runtime environment which one may use to implement a web server. Well, that's my opinion.
Saying node is a webserver is like saying javacript can only run inside a browser, you can say that but it can also do a lot of other things.
NodeJS
[Javascript runtime enviroment(Chrome v8 engine) + Node
Library/APIs]
Can create a web server, can also be described as a
Application server
Express
Web framework (uses nodejs's webserver to serve files)
Nginx
Web server
In production most people use Nginx in front of node server as a proxy server to serve static files and other various elements like caching, routing etc.
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.
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 allows functions to be called as objects. This allows the task to be executed immediately after an asynchronous request (e.g. to a file system, database or network) to be wrapped in a function and referenced as a parameter of the asynchronous request function call.
const mysql = require('mysql2');
const conn = mysql.createConnection(
{
host: "XXXXXXXXXXXXX",
database: "doa_statsbase",
user: "uoalabama_doas",
password: "*************"
});
. . .
. . .
const analyse_bigwheat_farmers = (err, result, fields) =>
{
. . . . .
. . . . .
return data_object;
}
. . .
. . .
let query = "SELECT * FROM us_farmers WHERE acreage > '1000' AND crop='wheat'";
mysql.query(query, (err, result, fields) =>
{
analyse_bigwheat_farmers(err, result, fields);
}
. . .
. . .
. . .
Not many other languages treat functions as objects and those that do may not have an interpreter as efficient as Google's V8 runtime. Most web developers already know JavaScript so there's no additional language learning with Node. What's more, having callback functions allows all user tasks to be put 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.
Today, most Node web applications use callbacks sparingly as JavaScript ES6 introduced the Promise construct in 2015 to handle asynchronous calls more easily and readably.
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 system (ApostropheCMS, Strapi CMS) updates, 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 ports (typically ports 80 (HTTP) and 443 (HTTPS) on the server machine where the web server program (Apache, NGinx, etc) will handle them in the mode of a traditional website.
[A side note here on request streaming to the server. Since most server machines' firewalls only allow the default ports 80/443 open, it is not usually allowed to directly send a Node.js request with another port in the URL, e.g. https://mynodeapp.com:3001/fetch-members. If one did, the server machine's firewall would simply ignore it as it directly references an illegal port.
Instead one could apply a URL to the request that has no explicit port number but which contains a virtual folder name that identifies the Node.js app, e.g. https://mynodeapp.com/mynodeapp/fetch-members. Then append some server directive code on the .htaccess file like:
RewriteEngine On
RewriteRule ^mynodeapp/(.*) https://localhost:3001/$1 [P]
Node.js requests given URLs in this way will thus find their way to the Node.js server for that web app via the nominated ports for the Node application, i.e. 3001 in the example here.]
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 JavaScript V8 engine. For example, the frontend build tools Grunt and Gulp use a frontend Node.js app to process a build script that can be coded to convert SASS to CSS, minify CSS/JS files, optimize image size or image loading, generate page-state HTML files for refreshing page-states in a single page application site, etc. But this sort of work is really just a by-product use of Node and not its principal use which is for making efficient backend processes for modern web applications.
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!!
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.
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.
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.
Although Nodejs is treated as a pretty cool, lightweight runtime environment and consists an awesome package manager called npm in node ecosystem. You can spin up a REST API, web application server using express framework which serves to a dedicated port. And it primarily required no web server on top of it.
whereas web server's main agenda is to serve as layer 7 loadbalancer and proxy server. According to Industry Standard most commonly used web server is nginx due to reliability. Although you can configure a http proxy server using node libraries and express framework.