Trees are awesome, but their usefulness is bounded by the human-friendliness of the UI. For example, a lot of apps use a hierarchical config where you can spec

Trees are awesome, but their usefulness is bounded by the human-friendliness of the UI. For example, a lot of apps use a hierarchical config where you can specify everything as YAML. Elasticsearch comes to mind. This works quite well because any property can be referred to as dotted keypaths, e.g. "discovery.zen.minimum_master_nodes". Kubernetes also uses YAML/JSON structures as a configuration interface. Kubernetes supports JSON Patch [1], a poor man's patching format for editing keys deep within a document, and it also supports JSONPath [2] for templating. But what these don't do is treat the entire config as a big tree, and I think that's a good compromise. Kubernetes stores all its config in Etcd, but this config is considered an implementation detail — you're not supposed to edit it directly — and moreover, Etcd is like a file system, not a key/value tree; Kubernetes maps each path to a file, not a single value. I like this approach, because individual objects can be validated separately by type. Kubernetes has a schema, which each object (YAML file) declares: apiVersion: extensions/v1beta1 kind: Deployment metadata: name: postgresql-master This maps directly to the version of the API that changes need to go through in order to make the configuration persistent. If you try to make one huge key/value tree, you're more likely to end up with something like the Windows Registry, a huge ball of spaghetti. [1] http://jsonpatch.com http://jsonpatch.com [2] http://goessner.net/articles/JsonPath/ http://goessner.net/articles/JsonPath/