The future of Nginx: Getting back to our open source roots

Re:The future of Nginx: Getting back to our open source roots by ravenstine on Wednesday August 24, 2022 @05:47AM (#32577111)

The configuration format is easily the worst aspect of nginx. There was a stretch where I got heavily into using it because it really is capable of quite a lot, but I could never totally grasp the config, despite how I've managed to learn pretty much any programming language given to me. Depending on what you're doing, a certain other thing may be totally moot or out of place, but it's certainly not obvious, and good luck actually debugging your nginx config without resorting to The Google. Once the config is set, nginx can do its job quite well, but it's bad if you're frequently making architectural changes.

[ Parent | on HN ]

Re:The future of Nginx: Getting back to our open source roots by minusf on Wednesday August 24, 2022 @06:53AM (#32577635)

every configuration format has it's quirks, and nginx certainly has a couple.

but coming from apache it was the freshest breath of air possible. i still prefer it to any yaml/json alternatives newer products like envoy use. a pure ymmv point.

i don't think that having a manual or reference open while doing more involved setups is a sign of bad design. some things are simply complicated...

[ Parent | on HN ]

Re:The future of Nginx: Getting back to our open source roots by Avamander on Wednesday August 24, 2022 @08:25AM (#32578444)

That's the thing, it's not a programming language. It's a sequence of declarations. In-spirit very similar to iptables or nftables rules for example.

Documenting things that took time for you to grasp is a great way to learn, in my experience.

[ Parent | on HN ]

Re:The future of Nginx: Getting back to our open source roots by ravenstine on Wednesday August 24, 2022 @12:31PM (#32581825)

I wasn't trying to equate it to a programming language, though. IMO, a config format shouldn't be more difficult to grasp than a Turing-complete language. To me, nginx conf is hard to gain proficiency in because the amount of experience to know whether a declaration is in the appropriate place or won't be ignored is very high. Obviously someone can indeed become proficient, but I've found it to be extraordinarily high for someone who just needs it occasionally; I really don't want to live in nginx land all the time, in part because I'm a software engineer and not really an ops person.

For instance, should `upstream` be defined at the top-level or under `stream`? If you have another server doing a proxy_pass to that upstream, does it also need to be under `stream`? This is in no way obvious by either looking at nginx configs or by reading the docs.

And then what if you have a web server? Does it need to be under `http`, or can it be top-level? It can be either one depending on who's config you're looking at. But if your server you're pointing to is already an HTTP server, why would you want nginx to use its own http serving on top of your HTTP server?

That's just a couple of examples. And yes, there are absolutely logical answers to those, but I do not believe that the nginx config format speaks for itself.

[ Parent | on HN ]