4 ms·

NGINX config language grates on me. Whyyy did they have to come up with their own config format? It is so much nicer to configure Caddy with JSON file for examp

NGINX config language grates on me. Whyyy did they have to come up with their own config format? It is so much nicer to configure Caddy with JSON file for example. Probably would also be much easier to statically check things about the config, than having to create a parser for NGINX config (or somehow integrate NGINX' own parser maybe). Probably the best one can do is either have NGINX at some point offer alternative config that uses JSON, or have some converter from JSON to NGINX config.

supriyo-biswas 2y ago
nginx unit[1] has JSON configuration. Although it's not terrible to write a hand-rolled recursive descent parser. [1] https://unit.nginx.org/configuration/ https://unit.nginx.org/configuration/
mmsc 2y ago
crossplane is an nginx<-->json converter: https://github.com/nginxinc/crossplane https://github.com/nginxinc/crossplane It works well, but probably doesn't solve your actual problem, because it still uses nginx _format_ -- just in json:)
MathMonkeyMan 2y ago
Nginx's configuration is the most flexible I've ever seen. When writing an nginx module, you have a handle to the config file being read, and you can do whatever you want. Conventions of syntax really are just conventions. There's no grammar. I'd prefer a formal language with a parse tree and all that, but I think the spirit of the nginx code is "just what you need and nothing more."
defanor 2y ago
As a counterpoint, I find custom formats to often be nicer than reusing generic ones: atomic values (individual lexemes, primitive types: strings, numbers, etc) tend to have custom formats or semantic restrictions anyway (say, dates, length-limited strings, range-limited numbers, though in some cases numbers are also just restricted strings), so that part is mostly handled from scratch either way. And then there is composition, with JSON--apparently the most popular format now--not having a standard way to encode sum types, so you basically have to hammer those on top. At which point it feels like building on top of a JSON structure instead of building on top of a sequence of characters, but not in a very different way: sometimes it is more helpful in some parts, sometimes adds more clutter than needed. Likewise with XML: it is not uncommon to see something like <my-custom-format>a string in a custom format here, or even a base64-encoded blob</my-custom-format>. In practice it is easier to use JSON for interfaces, since for someone unfamiliar with parsing it is less work to sort out on the other end, and then you have at least a partially specified structure, the rest can be easier to specify (with JSON schema, for instance), there are readily available libraries and tools to work with it, to do at least some of the parsing without writing a parser. But I think cleaner interfaces can be achieved with custom formats.

supriyo-biswas 2y ago

nginx unit[1] has JSON configuration. Although it's not terrible to write a hand-rolled recursive descent parser. [1] https://unit.nginx.org/configuration/ https://unit.nginx.org/configuration/

mmsc 2y ago

crossplane is an nginx<-->json converter: https://github.com/nginxinc/crossplane https://github.com/nginxinc/crossplane It works well, but probably doesn't solve your actual problem, because it still uses nginx _format_ -- just in json:)

MathMonkeyMan 2y ago

Nginx's configuration is the most flexible I've ever seen. When writing an nginx module, you have a handle to the config file being read, and you can do whatever you want. Conventions of syntax really are just conventions. There's no grammar. I'd prefer a formal language with a parse tree and all that, but I think the spirit of the nginx code is "just what you need and nothing more."

defanor 2y ago

As a counterpoint, I find custom formats to often be nicer than reusing generic ones: atomic values (individual lexemes, primitive types: strings, numbers, etc) tend to have custom formats or semantic restrictions anyway (say, dates, length-limited strings, range-limited numbers, though in some cases numbers are also just restricted strings), so that part is mostly handled from scratch either way. And then there is composition, with JSON--apparently the most popular format now--not having a standard way to encode sum types, so you basically have to hammer those on top. At which point it feels like building on top of a JSON structure instead of building on top of a sequence of characters, but not in a very different way: sometimes it is more helpful in some parts, sometimes adds more clutter than needed. Likewise with XML: it is not uncommon to see something like <my-custom-format>a string in a custom format here, or even a base64-encoded blob</my-custom-format>. In practice it is easier to use JSON for interfaces, since for someone unfamiliar with parsing it is less work to sort out on the other end, and then you have at least a partially specified structure, the rest can be easier to specify (with JSON schema, for instance), there are readily available libraries and tools to work with it, to do at least some of the parsing without writing a parser. But I think cleaner interfaces can be achieved with custom formats.