[CrLf]

The usefulness of this is not to turn nginx into an application server. Although there are already frameworks for this using ngx_lua (http://leafo.net/lapis/), I don't find them very interesting except for the technical aspect.

The point is to make nginx's configuration dynamic and prevent bloating applications with stuff that belongs at the (lets call it) devops level.

Now, I also don't think nginScript is such a good idea. But because they seem to be building their own JavaScript VM for it. I believe this is a waste of effort and more of a JavaScript-all-the-things than anything else.

Lua is a very simple language, the VM is small and fast and for the "dynamic configuration" scenario one hardly codes more than a few lines (I've done quite a few things and the total line count is in the low 100's).

[n42]

It's funny. Any feature you don't want to use is bloat, but as soon as you need it is a necessity. The way I see it, they can either "bloat" nginx by adding scripting capabilities, or they can bloat it by covering all of the use cases that a scripting engine would otherwise enable, big and small.

One simple example that I would love to use this for: generating and adding a UUIDv4 to every request's headers. Doing so would allow us to append the UUID to virtually every log in our entire stack. Right now there is no easy out of box solution for this in nginx. With scripting capabilities it becomes trivial.

However, whether or not Lua was enough and adding JavaScript is overkill, I'm not sure.

[erikcw]

I've had the following Lua adding request UUIDs to our logs in production for over a year. Feel free to give it a try:

https://gist.github.com/erikcw/e999e1fb438dbbb91533

[alexbilbie]

I do what you describe with no extra Nginx modules with the following line inside a location block:

  fastcgi_param X-REQUEST-ID $pid-$msec-$request_length-$remote_addr;

Using the more headers module you can also pluck things like Oauth access tokens and append them too

[marcosdumay]

> generating and adding a UUIDv4 to every request's headers

Why you can't do that in Lua?

[Dylan16807]

You can consider it bloat even if you want it, which is why you want to carefully manage the size of what you add.

I wouldn't refer to JavaScript as 'overkill'; it's not more capable than Lua for scripting, it's just bigger.

[madaxe_again]

We've written extensive partial view caching with memcached in lua in nginx, none of us having known lua when we started. It's fast as hell and the learning curve really isn't steep. Most of the tricky stuff involved the nginx api and brain-wrecking recursive and nested calls - not the language.

They're welcome to spend time building their own JS VM, it's their project - and while I don't think this is intended to appeal to the existing userbase, I think it will attract an entire new userbase, which will further nginx as a webserver and aid the goals of those who use it (faster. faster. more speed. faster. fix the bugs.) as they get more use, more paid use, and thereby more developer time.

[dunkelheit]

I have used ngx_lua in the past for some intelligent query rewriting and was very pleased with the experience. It is definitely great having the power of real programming language at hand and not being constrained by yet another configuration file syntax. On the other hand lua just feels very small and the temptation to fit more of the application logic into web server is low (although apparently not for others as lapis shows ;)).

I guess nginScript is mainly an outreach thing. Apparently nginx developers have decided that all those UI developers are just more comfortable writing JS than anything else. What indeed raises some red flags is that it is a subset of the language running on custom VM. So it is in fact a JS dialect which will still require some amount of learning to use it effectively (no free javascript lunch here).

[sciurus]

"The point is to make nginx's configuration dynamic and prevent bloating applications with stuff that belongs at the (lets call it) devops level."

No, let's not call it that, because I have no idea what you mean when you say that.

[CrLf]

Throttling, request routing, security workarounds, integrating multiple applications under a single nginx reverse proxy, ...

If you do ops or interact with an ops team, I'm sure you can find many more examples.

[sciurus]

Agreed, those are all operational concerns and dynamic nginx configuration is great for that. I was objecting to seeing the term "devops" being further abused.

[yc1010]

Some nginx configuration files are very project specific, especially when you have projects using some of the modules they offer.