nginx configs can be difficult enough on their own without constraining them to formats that wouldn't allow directives that take arguments preceding a block, not to mention the extra escaping that would come with quoting already-quoted strings. This is a common formulation:
location ~* \.(jpe?g|png|gif|ico)$ {
...
}
That would be pretty messy inside of JSON or YAML. You couldn't have the location line be a key for a map/hash, because you can have multiple blocks with the same "key".
Besides, as bad as nginx configs are, just trying to understand which block "traps" a request is where you can spend most of your time; see ifIsEvil [1].
Thanks for that comment. Running a complex nginx config with lot's of special treatment for subfolders on nginx - why and where a requests ends up in such a configuration is really difficult to tell.
However Apache just can't do some things that help you shooting in your foot. Maybe the C++ vs. Java comparison is not too far fetched.
nginx is one of those things that requires its own mentality to really get. Like SQL's set logic or CSS's forward-looking selectors, it's not quite like traditional imperative, control flow-based programming. But once you start thinking the way it wants you to think, there are benefits.
I'm in the middle of a project built entirely in nginx and it's astoundingly performant. The restrictions on what I can do in (mainline) nginx force me to think through how I structure the blocks and directives with better logic representative of a web server and not an application server, which is what I'm used to.
DigitalOcean has a decent tutorial on now nginx decides on server and location block [1]. And, related to ifIsEvil, this blog post [2] goes a little into explaining how nginx "traps" a request. If someone has better resources, I would appreciate them.
I've written a tool to tell us exactly that, called nginspex...hoping to open source it shortly. We use generated configs with tens of thousands of lines, for me this was an exercise in learning what nginx is up to as well as being able to say how a request will be handled.
The tool interprets the nginx conf, rather than compiling any of it (as nginx does with the rewrite rules), makes it easy to log which lines are involved in the processing as it hits them.
Besides, as bad as nginx configs are, just trying to understand which block "traps" a request is where you can spend most of your time; see ifIsEvil [1].
[1] https://www.nginx.com/resources/wiki/start/topics/depth/ifis...