Hacker News Reader

Comment by Olreich | Hacker News Reader

> They lay operational traps everywhere in their quest to get things done fast (like directly embedding config data in code to avoid fixing the config format).

Specific to your example, rather than the sentiment, I think embedding config in code is highly valuable when you don't have a lengthy deployment cycle and have direct access to the source. It gives your compiler more information which can help prevent bad configurations (which are the cause of failures more often than anything else from what I've seen). Developers also have a better shot at feeling how badly configurable a particular component is when the configuration is code. It's much easier to hide the overly-configurable systems under a rug when the configuration is far away from implementation, in a DSL, in a different repository, or only visible at deployment.

View on HN

I agree, configs in code are not a bad thing necessarily if they don't change often or at all. Sprawling config files are a significantly higher challenge to get your bearing with.

I’ve been trying unsuccessfully to get buy in on config as code.

Instead we have property / yaml files, read into anaemic “classes” which do not perform validation themselves. Validation duties are also foisted onto other parts of the system.

Stacked onto that we sometimes have file name based convention for defining a hierarchy of configs, to save on repetition between environments.

Config as code is fine as long as it results in a fully realized config that is then consumed by other code. All the big companies have almost certainly done it.

I would make sure when implementing it you have someone who is very opinionated review all configs to ensure that the same behavior is always implemented in the same way until a linter can enforce idioms. I would avoid explicit conditionals and explicit loops, instead relying on implied conditionals and implied loops. I would absolutely not use any "live" data, meaning the code should be relatively pure without any dependencies.

Pystachio is not a bad choice in python land:

https://github.com/wickman/pystachio

That was a bit ambiguous and there is a greater "should config be code" debate, which the "yes" people will always win eventually because it's so pragmatic.

Config will always move towards code as systems become more complex and scale up. At some point code-config will have an output intermediary data structure that is consumed by what consumes configs. I don't really have a problem with that.

I am talking about things like querying a database and inserting what would otherwise be a row in the database in the code that does the query itself. So if you need to do debugging, you go do a query against your database and the row isn't there. It sounds absurd, but I have seen it, and caused an outage because of it.

Reply on news.ycombinator.com