I am making a sample web application in node.js using express.js. I am getting a little confused when using apache-tomcat as my web server. I have two doubts:
When i run apache-tomcat as a web server and my express.js server is providing me services at port number 4000, how does it know at which port to listen to tomcat web server. and what if i have multiple instances of tomcat running on localhost, how will it know which instance of the server to connect to.
app.listen(port, "127.0.0.1");
And how does the following line of code works:
var server = app.listen(4000, function() {
var host = server.address().address;
var port = server.address().port;
console.log('server listeninig at http://%s:%s', host, port);
});
Why do we need to take help of apache tomcat or other web servers if we can provide web services using express.js only.
I don't believe that combining express.js (simple web server for Node.JS platform) and Apache Tomcat (Servlet container from JVM world) make sense at all.
I bet that you are confusing Apache Web Server with Apache Tomcat. They are two completely separate projects. If that is the case than notice that Apache Web Server or Nginx HTTP servers are often used with express.js as reverse proxies. This combination is often used to match security and performance (e.g. caching) requirements needed for PROD grade app.
To answer your question, no don't combine express.js with Apache Tomcat. If you are just starting playing with express.js, use it standalone. If it turns to be a app that should run in production, you will need to operationalize it, which would probably include considerations around combining it with some HTTP server.
Related
So I created an simple API using ExpressJS that connects to MongoDB to perform CRUD operations. Currently I am able to get the local host running by performing command "npm nodemon" in the source folder. And it worked by testing with postman I wonder how to implement it on the server. As server runs a linux system, also I have a line of code in my root file "server.js ":
const port = process.env.PORT || 5000;
I think the process.env.port needs need to be changed in order to make it work on the server?
In addition, I did look into aws CE2 server it is so complicated that I was immediately overwhelmed. I am hoping someone can recommend dummy like me a simple and very specific solution to have a server run my scripts in ExpressJS environment. Thank you
I'm assuming your question is "How to deploy express app to a server?"
You can read some advanced topics on http://expressjs.com/, which covers some best practices, and other useful stuff. But the things you want to look at now is Things to do in your environment / setup
The important part is:
Keep your express runing on port 5000
Run your app in cluster
Run your app behind a proxy server like Nginx.
You can check this nice guide (Step 3 and 4) on how to deploy your express app to a Linux server with PM2, Nginx.
So at the end, your express app will run on port 5000 (or whatever port you desire), and your Nginx will run on port 80, and nginx will forward any request to your express app.
I have node js server that has a server which listens 8000 port and a socket.io connection working on that server. This socket connection creates a communication with a ReactJS app which is not a point of this question. So I have 2 project folders
1. project-server
2. project-web-react
Project server only answers socketio request and does not render a HTML or something else. It only works on terminal. I want to ask whether is it useful to encapsulate my project-server with Nginx? So the requests are handled by Nginx ? Or is it out of the Nginx's purpose?
I would never have an application server run directly connected through internet since there are always a bunch of unknowns with them (scaling, standard compliance etc), so I would recommend you to run a proxy like nginx in front of your app. This also makes it easy to add certificates and do load balancing / caching. It just adds flexibility and some security.
I have a node app that I am trying to deploy on my server. I have an index.html file in a public folder and an app.js file. If I navigate to the project in the command line and run node app.js it runs the app on localhost:8888 and shows the index.html file.
Now that I have uploaded this to my server I am wondering what I need to do, and change (if anything) in my app.js file so that i can visit the site without visiting localhost:8888, but instead the actual url.
I have tried http://162.xx.xxx.xxx/folderName/app/public:8888, but this doesn't work.
var express = require('express')
var app = express();
app.use(express.static(__dirname + '/public'))
app.get('/', function (req, res) {
res.send('Hello World!')
})
app.listen(8888, function () {
console.log('Example app listening on port 8888!')
});
"Server" is a word with two primary meanings in software development.
It can mean either "A piece of software that listens on a network" or "A computer running that kind of software".
So having uploaded the JavaScript program to the remote computer that is your server you need to do exactly the same as you did on your own computer.
i.e. you need to get a terminal on the server and run node app.js
It will then be available at http://your.example.com:8888/
(More advanced uses would involve using software like forever or system.d to run it automatically as a background process).
If you were using the term server with the other meaning (i.e. you mean "Apache HTTP" or "IIS" or similar), then you are out of luck.
Using Node for server side code means running a server written in JavaScript.
To use this in combination with something like Apache, you would either:
Run the Node server instead of Apache
Run the Node server on a different port and point some services at that port explicitly
Run the Node server on a different port and use something like ProxyPass to have Apache relay requests to it
Change the port number from 8888 to 80 and then use the address of your server in the browser. For example, "mysite.com" for a domain name or "123.45.678" for an IP address.
If there are other sites on that server, you can't run it on port 80. (Port 80 is the default port websites use.) You'd need to use a different port. So, say you kept 8888 -- the address would be yoursite.com:8888
Whenever I deploy my Hapi.js web application to azure, it starts the server using the socket protocol (see output below).
socket:\\.\pipe\b5c0af85-9393-4dcb-bd9a-3ba9b41ed6fb
GET /
GET /{param*}
GET /api/employees
POST /api/employees
GET /api/employees/{id}
PUT /api/employees/{id}
DELETE /api/employees/{id}
POST /api/worklog
GET /login
POST /login
Hapi server started # socket:\\.\pipe\b5c0af85-9393-4dcb-bd9a-3ba9b41ed6fb
150914/214730.270, [response], socket:\\.\pipe\b5c0af85-9393-4dcb-bd9a-3ba9b41ed6fb: [1;32mget[0m / {} [32m200[0m (316ms)
However, whenever I am running this locally, it starts using http... I have not run into this issue using express or loopback, only Hapi. Is there some sort of configuration that I am missing? This is the server.connection function:
var server = new Hapi.Server();
var host = process.env.host || '0.0.0.0';
var port = process.env.port || 3000;
server.connection({host: host, port: port});
The reason this is a big deal is because I cannot pass socket://*<mydoamin>* to google as a callback URI for OAuth.
You shouldn't need to pass socket://<domain> to google, you'd pass the normal https://yourDomain.com or even the https://yourSiteName.azurewebsites.net to Google for OAuth callback and it should work as you would expect.
The fact that the node application is listening on a pipe rather than a normal tcp socket is just an implementation detail of iisnode. Basically the problem is that node has it's own webserver so you can't use it with other webservers like IIS, Apache, nginx, etc. iisnode bridges the gap between IIS and node in that it allows IIS to listen to the HTTP port on the machine 80 and when IIS gets a request on that port, it just forwards it to the node process that's listening on a named pipe. This allows you to manage your sites in IIS as you normally would on a Windows Server machine, while actually writing your app in node.
You can think of it as 2 webservers running on the box, one (IIS) is acting as a proxy for the other (node) where all the work is actually happening. The fact that the iisnode developer chose to use a named pipe instead of a normal tcp socket is odd (though kind of understandable since you can't easily reserve a port per se as you can a pipe), but it's the way it is.
I've successfully made a test chat app and I've gotten a node js server with socket.io running on heroku. On my local computer I have to specify the port number of localhost on the client side to the port that the server has set up. However, when I run my server code on heroku. Removing the server
I'm using the process.env.PORT variable since heroku sets that up:
var port = process.env.PORT || 3000;
http.listen(port, function(){
console.log('listening on *:' + port);
});
Naturally I find the port number that the app is running on place it in the url
var socket = io('https://xxxx.herokuapp.com:1111');
However this gives me an "net::ERR_CONNECTION_REFUSED".
I got it to work by removing the port nubmer after the url (in this example :1111). I'm wondering why this is working since most of the tutorials and articles online have it specifying the port and why my local computer needs the port to work as well.
When you connect to your https://xxxx.herokuapp.com subdomain on heroku on port 443 (which is the port that is used for an https connection when no port is specified), Heroku is probably using a proxy or router to route that incoming connection to the particular port that your node.js server is listening to. In the Heroku infrastructure, they know what actual internal host your server is running on and what actual port number it is running on so they can map a default port request on your subdomain to the actual port/host.
This is done so that browsers can connect to your subdomain directly on the default port without having to know the particulars of your node server installation and so that Heroku can auto-manage your server and likely share hardware with other customers. You are each running on a different port, but sharing the same machine. The ports are managed entirely by Heroku and this is one way that they are able to put multiple customers on the same hardware without each having to specify a custom port in the browser URL (which would be a non-starter for most customers).
So, Heroku is hosting some sort of proxy for your sub-domain that is listening to the default https port. Thus, you don't have to specify the port in the URL. Internally, they route that connection to your actual port on your actual server.
When running on your desktop, there is no such proxy to do this for you so you have to make sure client and server port numbers match.