My beef with it is that it's written in Javascript whereas what it does is so simple that they should just code it up in Rust or Go and be done with it, particularly when it could be packed up as a tiny binary that doesn't require you to install Node, Python, the JVM or any other runtime or library.
Show HN: From dotenv to dotenvx – better config management
221–223 of 223 posts
Re: Show HN: From dotenv to dotenvx – better config management
#222The whole idea of using environment variables for configuration information is good, but ultimately flawed, and we are way past the point where this should continue to be the status quo. Environment variables are great for configuration because: - you can inherit them from a previous application or application(s) - you can override them in each environment you run your app in - you can pass them on to other applicati…
Super early days but we're building something very similar to what you are describing over at 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 pluggabl…
The 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
Re: Show HN: From dotenv to dotenvx – better config management
#223Importing a set of library and dependencies to handle reading a plain text file poses more risks than just leaving the file unencrypted. You don't need to encrypt your keys, with what keys are you going to do so? Will you encrypt those? if someone is in your server you are pwned anyways. It's ok if you identify yourself as a cybersecurity dude and hold a cybersecurity role and you need to justify your livelihood. But…
completely agree. convenience is terribly underlooked in security judging by the reactions in this thread.
if the "secure" methods aren't being used because of 4FA and 5 rule passwords and 30 day expiries (don't get me started on this), then it is by default insecure because the devs will find more convenient ways, and thereby, less secure ways.
it's like storing passwords, i can't tell u how many times i've seen people use the same passwords everywhere because the rules are too restrictive. or just write it down somewhere public because it's too much work to get into the password manager and properly add it
i'd be willing to put big money down that a LARGE chunk of passwords for apps that require at least 1 number or symbol largely end in `!` or `1` at the end.
luckily i do think passkey is a step in the right direction with good convenience and overall ux