You could accomplish the exact same thing with the following in a release:
defmodule MyApp do
use Application
def start(_type, _args) do
import Supervisor.Spec, warn: false
repo_env = Application.get_env(:indexer_spike, Repo)
configured_env = put_in(repo_env, [:database], ConfigDb.get!("/postgresql/database"))
Application.put_env(:indexer_spike, Repo, configured_env, persistent: true)
children = [
...
]
Supervisor.start_link(children, strategy: :one_for_one, name: __MODULE__.Supervisor)
end
end
In other words, load your configuration from the database and push it into the application env prior to starting your top-level supervision tree. If you have dependencies you need to configure this way, you can add them to :included_applications and place them into your top-level supervisor, or use Application.ensure_all_started(:app) in the start callback.
You don’t have to configure everything in the application start callback either, you can handle individual configuration values in the worker/supervisor init callbacks, where you can do all the validation you’d need to do anyway, and fail the init if the configuration is missing or invalid. Move shared validation logic to a Config module. This is the way it should be done in my opinion. Just because Mix’s config file lets you do this doesn’t mean it’s the right place to do it. Use Mix’s config file to set defaults, use the env-specific configs to set a priori config values (i.e. things you can configure ahead of time because they don’t change from host to host), and do the more complex host and env-specific configuration at runtime, in the application itself - you get all the benefits of writing Elixir code, except now your configuration logic lives next to the thing it’s relevant to. And hey, as a side-effect, you can use releases painlessly!
