Hacker News Reader

Comment by a_imho | Hacker News Reader

Regarding Architecture B, I was always curious why use nginx as a proxy to node? In my experience it is perfectly capable as an application server as well (OpenResty in particular), no need for yet another component.

Also, I consider deployment via Docker a sensible default with all the niceties in tooling. For example I find it convenient to set a restart policy on the container process.

View on HN

The main reason I use nginx is because it is so easy to configure HTTPS with LetsEncrypt & Certbot. Perhaps there's an almost equally easy solution now that only uses node, but last time I checked (2018) it was messy.

In this article (https://medium.com/intrinsic/why-should-i-use-a-reverse-prox...) there's another good reason: by not making node manage the HTTPS certificates, no node library that I use (directly or indirectly through a dependency) can represent an attack surface regarding the certificates. But I must confess this is marginal compared to the ease of installation and maintenance that I already mentioned.

Another good reason is that once you start running multiple apps with different tech stacks, it's so much nicer to be able to take care of the config using the regular sites-enabled 'workflow'! I have a server that runs a node app, and a few Phoenix apps, and all I have to do on the nginx end is forward to the correct port (and of course set up https with LetsEncrypt is real easy too).

I always throw Nginx in front of Node so I can route statics to the filesystem (Don't serve js or CSS through NodeJS), plus it means I can run new NodeJS services and adjust the routing in Nginx to point to them.

Also Fail2Ban reads Nginx logs

I read architecture B as a single server scenario, the question was why use Node in that case instead of handling everything in nginx (if you are set on using nginx anyway) for a minimal setup. Of course the same can apply the other way around, but I gather Node is just not good at some of the things nginx is.

I don't think it is at all possible to use nginx to write application logic otherwise than serving static files and perhaps doing some URL transformations. node gives you a full programming language that's necessary for implementing an API.

It is absolutely possible, that is what the OpenResty stands for.

I stand corrected, you're right! I hadn't heard about OpenResty.

It's amazing that this exists, I would have never thought it possible (because of what I saw as inherent limits in what can be expressed in terms of nginx configuration), but now that I see it, of course it is :). From what I gather, custom code can be written as Lua scripts, and many of the modules are written in Lua themselves.

Thank you for sharing this!

As far as I remember Lua scripting is brought by the lua-ngx module, but it is also possible to use JS or the JVM (ngx-clojure) for location handler, or even write your own nginx module in C, nevertheless Lua is the first class citizen. I personally don't mind it, but obviously the ecosystem and the market for Lua is much smaller than JS. In fact, I'm only aware of itch.io that runs on OpenResty.

It looks like Lua is the main scripting language; which is a fine choice by me; the few times I worked on redis transaction scripting in Lua (since Lua is the language for doing that) the experience was very pleasant.

Are you building a project (or projects) on OpenResty?

I think the pattern is

    Public Web -> Reverse Proxy -> Application Server

Rather than

    Public Web -> Nginx -> Node (In his example)

You could reasonably do

    Public Web -> Node reverse proxy -> Node Application Server

It doesn't really matter if the reverse proxy is Nginx or Node or something else, it's a good pattern to insert a lightweight service at the front which can redirect the requests upstream. If you need to scale by adding new boxes or services, this can now be your load balancer.

Your reverse proxy can also handle blocking dodgy requests (Fail2Ban) or act as a lightweight static file handler, leaving your application server to do the grunt work.

+1, although the author does explain:

> [nginx's] main use is to provide HTTPS support

I've been using nginx purely for HTTPS stuff because I have been too lazy to learn how to do it with node. When working on little no-user-info sites that don't need SSL, I have cloudflare in front with no encryption to the origin (just an A record pointing at the IP of the server), and then just have a simple express app which proxies the requests on port 80 to apps on 3000, 3001, 3002, etc. based on the host header - makes me so happy compared to playing around with nginx config files.

Reply on news.ycombinator.com