5 ms·

For the love of god, if anyone reads this, please don't do this! Config files are fantastic. Trivial to read, write, copy, track in version control, diff, grep

by twic 7y ago

For the love of god, if anyone reads this, please don't do this! Config files are fantastic. Trivial to read, write, copy, track in version control, diff, grep, generate with scripts, etc. API-driven configuration has none of these properties. Some Java application servers take this approach of API-driven configuration. It's an improvement over UI-driven configuration, which is what they had before. But it's still significantly worse than simple file-driven configuration. If you want to provide a 'friendly' CLI tool, by all means do so - but provide a tool to interpret and generate config files, not something which replaces config files.

flukus 7y ago
> Config files are fantastic. Trivial to read, write, copy, track in version control, diff, grep, generate with scripts, etc. Code based configuration offers most of those benefits, just look at some of the suckless tools, if you've never used dwm or written a line of C I bet you can still guess how to configure some stuff here: https://git.suckless.org/dwm/file/config.def.h.html https://git.suckless.org/dwm/file/config.def.h.html . It doesn't work for all software of course, but for anything developer centric and/or anything with complex configuration done by experts it's a good choice, particularly for any software going down the path of creating a custom language (tmux, vim, etc). You get the power and flexibility of a full programming language, you get compile time config checks, you get excellent performance, you don't have to learn yet another config language and it's easy to write patches. It's not great if you're targeting Joe Average, but neither is any configuration format, or any configuration at all.
vinay_ys 7y ago
Config variables in code gets version controlled and release-managed alongside code and takes the same CI/CD route to production as rest of your code does. Your code asserts, compilers and test cases can help you catch errors in config data. All of this happens without any special file format or parser concerns. If you need runtime reconfiguration in production, then it requires a runtime config management system tailored for operations folks with proper authn/authz, audit logs etc. This is a product by itself. The connection between your running program and the runtime configurator has to be intentional, secure etc. IMO, config variables should have following bindings: 1. config variable in code. 2. program start env variable. 3. program start command argument flag. 4. runtime configuration. All available configuration options are declared in the code. But not all configuration options should be accessible from #2 to #4. And the override preference order may not be same for all types of configuration variables. Btw, this isn't related to Java or any particular programming language. I've seen this done in large C++ projects 20 years ago.

by twic 7y ago

flukus 7y ago

> Config files are fantastic. Trivial to read, write, copy, track in version control, diff, grep, generate with scripts, etc. Code based configuration offers most of those benefits, just look at some of the suckless tools, if you've never used dwm or written a line of C I bet you can still guess how to configure some stuff here: https://git.suckless.org/dwm/file/config.def.h.html https://git.suckless.org/dwm/file/config.def.h.html . It doesn't work for all software of course, but for anything developer centric and/or anything with complex configuration done by experts it's a good choice, particularly for any software going down the path of creating a custom language (tmux, vim, etc). You get the power and flexibility of a full programming language, you get compile time config checks, you get excellent performance, you don't have to learn yet another config language and it's easy to write patches. It's not great if you're targeting Joe Average, but neither is any configuration format, or any configuration at all.

vinay_ys 7y ago

Config variables in code gets version controlled and release-managed alongside code and takes the same CI/CD route to production as rest of your code does. Your code asserts, compilers and test cases can help you catch errors in config data. All of this happens without any special file format or parser concerns. If you need runtime reconfiguration in production, then it requires a runtime config management system tailored for operations folks with proper authn/authz, audit logs etc. This is a product by itself. The connection between your running program and the runtime configurator has to be intentional, secure etc. IMO, config variables should have following bindings: 1. config variable in code. 2. program start env variable. 3. program start command argument flag. 4. runtime configuration. All available configuration options are declared in the code. But not all configuration options should be accessible from #2 to #4. And the override preference order may not be same for all types of configuration variables. Btw, this isn't related to Java or any particular programming language. I've seen this done in large C++ projects 20 years ago.