Replies: 1 comment
-
The behaviour is already in-place. However, it's currently designed only with OS env in mind, so it's possibly not sufficient for other sources which require a process structure (e.g. if a live connection to the source needs to be maintained).
Yeah, currently you can do this by creating one module for each data source. This is a clean separation, though it admittedly leaves some work for the client. I'd leave it as is for the moment, because the mentioned scenario can be implemented with the current API. We can always reconsider down the line, when we get more feedback. |
Beta Was this translation helpful? Give feedback.
-
My comment here talks a bit about the potential of multiple backends. What could this lib do in order to support multiple backends? My initial thought would be to create a behaviour that could be implemented for various ways retrieve the needed configuration. e.g., ENV Vars, Hashicorp Vault, AWS Secret Manager, etc.
The real problem that I could see happening is that someone may want to take advantage of the dynamic secrets for creating database username and password in Hashicorp Vault, while using a regular ENV Var in order to specify the databases URL endpoint.
Is this something we should consider implementing? Allow creating your configuration to spread across one or more different providers? Or should that be more about creating one configuration per provider that you want to incorporate into your application?
Beta Was this translation helpful? Give feedback.
All reactions