As far as I understand, Meteor is a full-stack web server, meaning you don't need another web server such as Apache or NGINX to makes it work. But from reading the guidelines on deploying Meteor, it seems like they use NGINX to serve Meteor.
Why is this?
Edit: Will there any impact if I just use the Meteor without NGINX or apache? Is it significant?
Meteor is not a web server. Especially, it cannot terminate SSL/TLS. That's why you might want nginx running in front of meteor.
Nginx placed in front of the Node.js build of your Meteor app tends to double the throughput of serving static assets (images, media files etc.) and reduce latency - see these benchmarks by #Stephan at Do I really need nginx with my Meteor/Node.JS app?
See also the recommended nginx configuration for Meteor.
Related
We want to host the application on IIS server. We need it to support dynamic routing.
We tried downloading IIS node and we're not sure how to proceed.
Is there a file that needs to be loaded and needed to run, such as server.js?
You will need to install nodejs on the host system and have server running on a port, then use IIS as a reverse proxy on top.
This article goes into detailed steps on how to get there - https://alex.domenici.net/archive/deploying-a-node-js-application-on-windows-iis-using-a-reverse-proxy
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 know that node.js server caches modules. So, after starting the server all files get "compiled" and all your changes to code can take effect after restart the server.
But if there are always hundreds of users online on website - how do you make those changes (restart server) in a way your hundreds of client won't notice any trouble, downtime?
Please, give me some guide and (your own) examples about (I guess) scalability, balancing load on servers etc, so I can make awesome large and dynamic website with node.js too.
The best way to accomplish continuous uptime with Node.JS is to have 2 Node servers running and proxy to them using nginx and upstream providers. That way you can restart one whilst the other takes the traffic load then do the same to the other node server.
Your nginx configuration would use something similar to the below:
upstream backend {
server backend1.example.com weight=5;
server backend2.example.com:8080;
server unix:/tmp/backend3;
server backup1.example.com:8080 backup;
server backup2.example.com:8080 backup;
}
server {
location / {
proxy_pass http://backend;
}
}
For more information about nginx proxying and upstream providers see the nginx documentation: http://nginx.org/en/docs/http/ngx_http_upstream_module.html
From what I have read so far in this blog http://nowjs.com/ I need to install nodejs in the server machine for it to work. But, I am using a shared server and don't really have any authority to put something into the server machine.
Putting it into the container(tomcat) is however another thing which I mostly do.
Generally speaking, when we say server we mean tomcat or websphere or jboss.
But with nodejs if I am not wrong server means the real machine on which tomcat etc. runs.
So is there any way I can run the nodejs server inside tomcat server or am I thinking about it the wrong way ?
Yes, you are thinking of it it the wrong way. The key feature of Nodejs is that it contains, amongst other things, a rather natty embedded HTTP server. Think Jetty. However it might be possible now or in the future to run JavaScript in tomcat.
I recommend going to http://nodejs.org/ and watching the video, it will surely clear the matter up for you.
Meanwhile I would recommend getting hosting which includes SSH access, and preferably root access. Root access will make installing node a whole load easier and allow you to run it on a commonly used port (avoid running node as root, use port mapping) . But you don't need a seperate web server to get started, you can install Node.js on windows, mac and linux.
Ok so I have read through the Socket.IO docs and I am still a little unsure of a couple of points:
The documentation says...
To run the demo, execute the following:
git clone git://github.com/LearnBoost/Socket.IO-node.git socket.io
cd socket.io/example/
sudo node server.js
Now I don't know what this means at all! I think it may be command line interface. I of course have access to this on my localhost, but my online hosting package is a shared LAMP setup. Meaning I don't have access to the root command line (i think).
How do I actually setup socket.IO, is it impossible on my shared server package?
Appreciate any help...
W.
If you aren't familiar with node.js or with basic command line usage then I would suggest that you use a hosted WebSockets solution like pusherapp. Trying to learn WebSockets, and Node.js, and the Linux command line all at once is going to lead to a lot of frustration. Take a look a pusherapp's quick start guide, it's very easy to get started. You can have 5 simultaneous connections with a single application for free (I'm not affiliated with pusherapp).
Updated (with inline answers to questions):
If you are going to go the direction of running a Socket.IO application:
You don't technically need git since you can download node.js and Socket.IO from their respective download links on github.
You don't actually need a LAMP server to use Socket.IO. By default Socket.IO functions as a simple webserver in addition to a WebSockets server. If you want server side scripting then you might want Apache with mod_php, mod_python, etc.
You don't technically need a dedicated server or even root access. You do need a system where you can have long running process. And if you want the service to start automatically when the system is rebooted, you probably want to add a startup file to /etc/init.d, /etc/rc.d which will require root access. Both node.js and Socket.IO can be installed and run from a normal home directory. If you want to run Socket.IO on a standard port like 80 or 443 then you will need to run it with root privilege.
Node.JS scales quite well so Socket.IO will probably scale pretty well too.
It's not a simple matter to get everything setup and working, but if your goal is a free solution for web serving+WebSockets then Socket.IO is probably is good route to at least explore if you are brave.
First you'll have to determine if your host supports SSH. Sometimes they don't by default on shared hosting, but if you ask they can turn it on. If it does you'll use some sort of SSH client to connect to it. Putty for windows is the most common. Then you'll use git, which is a source control program. Which you'll probably have to install on your host, which may or may not be allowed. If you can, this can be accomplished a number of ways, you'll want to read the git documentation, it will depend largely on what linux distribution you're running. CD is change directory, basic command line stuff. sudo on the last line is telling the system to run the command as root, which it will ask you the password for, which you may not have access to on your host. Sounds like you're gonna have an uphill battle on shared hosting. You may want to opt for a VPS instead.
If your shared host is a LAMP system with no command line access you're not going to get very far with Socket.IO. The instructions you posted assume you have command line access and that you've installed the node.js runtime on your system.
If you really want to try this I recommend you get a VPS of your own (I use prgmr.com) to test it out. For what it's worth I found the Socket.IO platform pretty nice to use once I got it up and running.