just a quick question.
What would be more beneficial, serving my angular application via node with a reverse proxy from nginx or just serving it directly from nginx?
I would think it would be faster to serve it direcly from nginx.
If there is a clean separation of your client-side code and your server side code (e.g so anything the client needs to run is either pre-built into static files or served using your rest api), then it's far better to serve the client-side files either directly from NGINX or from a CDN. Performance and scaling are better, and there is less work for you to do in code on the server to manage caching, etc. plus you can later scale the api independently.
nginx(as a reverse proxy) + nodejs - It's the best choice.
You will have much more benefits if you choose nginx as a frontend for nodejs. (ssl, http2, configuration, load balancing etc.)
If we think about static files (js, html, images) - it's more easier to cache them in one place (nginx host config) node also works with static file quite good.
I think that nodejs engine/server should do only one thing and it's business logic of the application.
Depending on your load requirements. You can setup multiple instances(runtimes) using nginx+node. If you have high load js application, i would suggest going for this solution. Otherwise, this does not matter.
Related
Can I / Should I host Angular, Node-express and Mongo on same server, say localhost:3000 or somehosting.com/server-address?
Also is it a good practice?
I've seen Angular and Node running on same server, but what about adding mongo too?
like everything equivalent to
mongodb://localhost:3000/db
ng serve --port 3000
server listen(3000)
Thanks
As you have not mentioned for what purpose - the answer will be depending on the purpose and context. If you are learning, then running webserver, database and serving Angular static files , all from the same server is not an issue. However, if you are going to have live web app, even with less or moderate traffic, then you must run database on its own server, and the webserver and static Angular files from one server. Of course, for SPAs that expect lot of traffic and real use, it is better to serve your static Angular files from a CDN or storage service like AWS S3, and web and database servers separately.
Happy learning!
It is best practice to keep the databases(stateful) in different servers then the applications(stateless) unless it is just for testing...
I was going through Uber Engineering website where I came across this paragraph and I it confused me a lot, if anyone can make it clear for me then I would be thankful to him/her:
The Edge The frontline API for our mobile apps consists of over 600
stateless endpoints that join together multiple services. It routes
incoming requests from our mobile clients to other APIs or services.
It’s all written in Node.js, except at the edge, where our NGINX front
end does SSL termination and some authentication. The NGINX front end
also proxies to our frontline API through an HAProxy load balancer.
This is the link.
NGINX is already a reverse proxy + load balancer, then from where HAProxy load balancer came in the picture and where exactly it fits in the picture? What is "the edge" he talked about? Either the guy who wrote his he wrote confused words or I dont know English.
Please help.
It seems like they're using HAProxy strictly as a load balancer, and using NGINX strictly to terminate SSL and for authentication. It isn't necessary in most cases to use HAProxy along with NGINX, as you mentioned, NGINX has load-balancing capabilities, but being Uber, they probably ran into some unique problems that required the use of both. According to the information I've read, such as http://www.loadbalancer.org/blog/nginx-vs-haproxy/ and https://thehftguy.com/2016/10/03/haproxy-vs-nginx-why-you-should-never-use-nginx-for-load-balancing/, NGINX works extremely well as a web server, including the use case where it is serving as a reverse proxy for a node application, but its load-balancing capabilities are basic and not nearly as performant as HAProxy. Additionally, HAProxy exposes many more metrics for monitoring, and has more advanced routing capabilities.
Load balancing is not the core feature of NGINX. In the context of a node.js application, usually what you would see NGINX used for is to serve as a reverse proxy, meaning that NGINX is the web server, and http requests come through it. Then, based on the hostname and other rules, it forwards on the HTTP request to whatever port your node.js application is running on. As part of this flow, often NGINX will handle SSL termination, so that this computationally-intensive task is not being handled by node.js. Additionally, NGINX is often used to serve static assets for node.js apps, as it is more efficient, especially when compressing assets.
I'm building a Node.js applications and I'm using nginx as a reverse proxy. My application has some static files I need to serve and a Socket.io server.
I know that I can serve static files directly with Express (using express.static middleware). Also I can point nginx directly to the directory where my static files are located, so they would be served by nginx.
So, the question: which one is the better approach? Which pros and cons can I face while using each approach?
for development: express, mainly because of flexibility it provides... you can change your static location and structure very easily during development
for production: nginx, because its much much faster. Node/express are good for executing logic, but for serving raw content... nothing can beat nginx. You also get additional capabilities such as gzip, load balancing...
Nevertheless, this question has been asked in stackoverflow a number of times already: see
node.js itself or nginx frontend for serving static files? or
Using Node.js only vs. using Node.js with Apache/Nginx or
Which is most efficient : serving static files directly by nginx or by node via nginx reverse proxy?
The Express documentation explicitly recommends using a reverse proxy where possible. To quote from this article:
Nginx can do a much better job of handling static files and can prevent requests for non-dynamic content from clogging our node processes.
There's an awful lot of articles discussing the subject which go into greater detail, but I would definitely heed the recommendations made by the Express developers.
Why should I proxy requests through to my Node.JS server using something like Nginx?
Why not allow access to the node server directly?
Internet is unfriendly and hard to survive place.
Having Nginx between your client and Node.js obviously allows you to use the advantages Nginx offers. So what are these?
HTTPS can be set-up without touching any code in your Node application. It is tricky otherwise, and can compromise your HTTPS private key, if Node app can be exploited.
Gzipping the communication can be done avoiding any changes in Node application.
Authorization. For instance, Nginx can automatically block unwelcomed spiders.
If you have more than one application, Nginx will serve as an independent router.
And more...
Summing it up, Nginx will do the server stuff, so that developing your application, you do not need to worry about the administrative and common configuration aspects of a web server.
I recommend you to read chapter 3 of "Deploying Node.js" by Sandro Pasquali (Packt Publishing) specially from page 69 onwards.
I will cite a couple relevant of paragraphs:
Using Nginx
According to
http://www.linuxjournal.com/magazine/nginx-high-performance-web-server-and-reverse-proxy:
"Nginx is able to serve more requests per second with less resources
because of its architecture. It consists of a master process, which
delegates work to one or more worker processes. Each worker handles
multiple requests in an event-driven or asynchronous manner using
special functionality from the Linux kernel (epoll/select/poll). This
allows Nginx to handle a large number of concurrent requests quickly
with very little overhead."
Load balancing with Node
File serving speeds are, of course, not the only reason you might use
a proxy such as Nginx. It is often true that network topology
characteristics make a reverse proxy the better choice, especially
when the centralization of common services, such as compression, makes
sense.
I want to ask about some good practices. I have a Node.js (Express) web server and socket.io push server (in case technology matters). I can turn both of them into one application but I want them separated (they can communicate with each other if necessary). There are two reasons to do that:
It will be easier to manage, debug and develop the app;
It will be a lot easier to scale the app. I can just add another instance of push server or web server if necessary;
This is at least what I believe. The only problem is that when a client connects to the seperate socket.io server then it won't send cookies (different port, cross-domain policy).
The workaround I came up with is to put a reverse proxy (written in Node.js as well) in front and check what kind of request we are dealing with and send it to web server or push server accordingly. Great, now we have cookies in both web server and push server. The reverse proxy can be a load balancer which is an additional bonus.
It looks like a good idea to me. What do you think about this design? Perhaps any other workaround for cookie problem?
I recently did something simular, we initially used a node.js reverse proxy but ran into reliability/scalability problems. We found serving static files and proxying requests was best left to nginx. haproxy is also a very viable solution for stand alone proxying as well.
HaProxy
Nginix as a reverse proxy