4 ms·
So, my opinion is based only on perhaps 1h playing with it. I have mixed feelings about this. It's definitely neat, but I don't like that it adds quite a bit of
by marcyb5st 8y ago
So, my opinion is based only on perhaps 1h playing with it. I have mixed feelings about this. It's definitely neat, but I don't like that it adds quite a bit of cognitive overhead (again, this might be because I'm not fully used to it). I believe configurations shouldn't force you to think "how will this be rendered?". For my personal projects I started using protobuffer text formats as configurations. Having the proto definition is the only docs you need and you get meaningful errors when you misconfigured/forgot something.
Sure, the text format is quirky, but so far it works quite well for me and protobuffers (v3) can be easily rendered as JSON.
- krisrm 8y agoI agree with this sentiment. I work primarily in web dev, and the stacks are already so sprawling with different technologies... config file generation debugging just sounds like unnecessary hassle. Had not heard of protobuffers before though, and it does look pretty neat.
- marcyb5st 8y agoGlad to hear :) I must admit that protobuffers v2 might be best for configurations files, given that they have the "required" keyword on fields and the generated code has methods like "hasFieldX() -> bool" which proto v3 dropped in favor of simplicity.
- stubish 8y agoIs there any particular advantage to text format protobufs, rather than the JSON or YAML representations? I've avoided the text format, as I couldn't find it documented, and it seems easier to unmarshal YAML or JSON using the Python or Go APIs. I do agree that your approach seems good. Alternatives such as jsonschema seem to have much worse syntax, tooling and language support. And we don't discuss XML schemas in polite company.