Hacker News Reader

Comment by jinglebells | Hacker News Reader

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

View on HN

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.

Reply on news.ycombinator.com