I wanted to solicit the community’s knowledge/experience/recommendations on this one…
Let’s say you’re working with an application that gets deployed to production and you rely on a configuration provider (e.g. secrets_manager_provider | Hex but it doesn’t particularly matter which one).
The problem this solves is that now you can inject sensitive values directly into your Application’s process dictionary. Yay!
However, this creates a new problem: the Application process dictionary no longer has a single source of truth. We don’t know its state! With the introduction of a custom configuration provider, we no longer have a nice mapping from simple config files to Application values.
If we were relying on just runtime.exs, we could easily enforce that certain values be supplied by the environment, e.g.
import Config
config :my_app, :something, System.fetch_env!("SOMETHING")
And that creates a strong contract with the environment: the app will not start unless it is properly configured. This is the approach I leaned into with the dotenvy and it has worked well.
But with a configuration provider, we can’t take the same approach… we might not even use runtime.exs. So we have to move our “defenses” out of the configuration files and retreat into the application itself to verify that our app is configured properly.
Even if our app favors the use of Application.fetch_env!/2 over get_env/3 that’s no guarantee that it has the values it needs when it starts. With the use of the custom configuration provider, we can no longer guarantee that our Application’s process dictionary is in a good state.
How do we defend against this? We could put some code into our app’s start/2 function, e.g. something like:
@impl true
def start(_type, _args) do
Application.fetch_env!(:my_app, :something) # <-- blow up before start
children =
[...]
# ...
But that feels redundant.
What are other ways to guard against this? Am I missing a trick here? Thanks in advance!
