Hacker News Reader

Comment by vinay_ys | Hacker News Reader

I strongly recommend doing away with config files completely for sake of ease of use, maintainability and security.

Instead just declare all config variables within code itself in a separate config class/module file, along with initialization to default values and provides dynamic getter/setter interface over a debug API (which can be enabled/disabled via a command line flag).

If you want, you can also provide a friendly cli tool to interact with the debug api. This tool could output help messages, show current config values - differentiate between default vs overwritten etc.

Of course, this can be written once as a utility library and cli and used consistently across all your programs.

View on HN

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.

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.

> 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 .

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.

> If you want, you can also provide a friendly cli tool to interact with the debug api. This tool could output help messages, show current config values - differentiate between default vs overwritten etc.

And we load the config by curling a JSON payload :) ?

This breaks when you have multiple services in potentially different programming languages that need to read the same config values.

I follow this plan in many (maybe most) app config situations, but it has at least two noteworthy drawbacks:

1) it presents an obstacle to sharing config files in a multi-language environment.

2) writing user prefs in the host app’s native language is fraught with security issues

The first concern is admittedly niche, and both concerns are addressable with some care and thought, but they’re good to consider.

This is not going to make you many friends in the server community (think apache, mysql...)

I went from that to INI to TOML and back to that in 10 years.

It just makes things run smooth in TypeScript because all the members and types can be statically analyzed giving you errors, auto completion and ability to jump to the definition when config files cannot do that but probably not good for large projects with multiple languages.

For small projects I'm just taking the benefit over small concerns.

How did we get to this point?

Reply on news.ycombinator.com