Skip to content

Comment on Definitely an OpenResty guideparent

Comments

On the face of it that's not very practical indeed, but that doesn't mean it isn't necessary in real-world scenarios. You don't always control the applications behind your nginx reverse proxies and can't always enforce correct behavior from them. They may come from a separate group which you can't easily reach for political reasons or from some external vendor with its own roadmap.

This makes OpenResty a nice tool for operations/security, because you have enough control to implement workarounds when required without having to wait for external entities. Some of you may cringe at the notion of implementing workarounds, but that's standard practice in any corporate setting. The alternative is just worse and you learn to live with it by calling it "application firewalls".

The other nice thing about OpenResty is the flexibility gained from separating scaling/infrastructure logic from application logic. And this got even better in the last relase of the Lua module by allowing custom balancing logic in upstream blocks without having to hook into header_filter_by_lua or something like that to manipulate the URL to feed into proxy_pass.

Finally, there's microservice (or microapplication) architectures, where your big application is really a bunch of smaller applications being glued together by logic in nginx (something like Edge Side Includes but nicer).

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.