Hacker News Reader

Comment by exceptione | Hacker News Reader

I think it is very cool openresty works with lua instead of javascript. But the given example lets me wonder about its practical use:

Suppose before forwarding the data POSTed to your application you want to do certain checks on the data so that you can be sure that your application receives only the clean refined data to operate upon. (...) So your application layer can focus on working upon it without worrying about cleansing it first.

I would think that dealing with incorrect data should be handled by the application rather than nginx. If you want to expose your application via other means it means you don't have to duplicate your validation logic. Think also about giving feedback about the incorrect POST-data, I think your application is better suited to provide that, as it can return a <form> with carefully placed messages for instance.

View on HN

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).

> I would think that dealing with incorrect data should be handled by the application rather than nginx. If you want to expose your application via other means it means you don't have to duplicate your validation logic. Think also about giving feedback about the incorrect POST-data, I think your application is better suited to provide that, as it can return a <form> with carefully placed messages for instance.

A good chunk of traffic is bot exploit traffic and rejecting that silently at the proxy level is a viable option [its basically what Cloudflare, among others, use OpenResty for].

Incorrect data should go to the application, malicious data should be dropped before it gets there if practical.

What I wanted to say was.. openresty is like a second application server + proxy combined into one. So you can have some of your validation at proxy level itself and reject dirty data then and there without ever having to bother your application server.

>as it can return a <form> with carefully placed messages for instance.

Openresty can also do that. The choice may vary from person to person. But the point I was trying to make was that if I have to use nginx I'd rather use openresty. And if I use openresty I'd probably do all little tasks like validation at the proxy level itself.

I agree that's a bad use case for openresty. But by the same token, you can move logic that doesn't belong in a particular application to a simple lua script, perhaps with delegation to another service. So in general, I think, openresty helps improve separation of concerns rather than hurting it.

Reply on news.ycombinator.com