3 ms·
Super early days but we're building something very similar to what you are describing over at https://dmno.dev https://dmno.dev Granted our solution is more ja
by theozero 2y ago
Super early days but we're building something very similar to what you are describing over at https://dmno.dev https://dmno.dev
Granted our solution is more javascript/typescript focused - and the config schema will be defined using TypeScript and piggyback on npm for sharing plugins/extensions. But the config will be usable in any language (and generate types for multiple languages) with deeper integrations coming soon.
The pluggable nature of our architecture also means you can encrypt secrets in your repo if you want to, or sync with other backends. Shouldn't be too hard to keep everything away from env vars either if that's what some folks want.
Would love your input, and to hear what you think!
- 0xbadcafebee 2y agoThe feature list looks great, but it looks like it's trying to bite off too much at once. - Supporting a particular repo type is an engineering smell (over-complicated/over-opinionated/tightly-integrated); this should be repo-design-agnostic - The "dmno service" is also biting off too much, this should not be a concept inherent to the configuration library - Schemas should be optional - Data types are fine, but get complicated, especially when mapping between different data formats/containers/transports; it's probably better to start with only a couple types and grow them over time if needed - Inter-service dependency management is also too complex for this solution - Plugins are a good idea - Three different package types? Complexity... - The security features are great I get that you're trying to sell a product, and so having a big kitchen sink makes it more attractive to buy, but it makes for more complicated solutions which then annoy users.