Shared config instead of per-app config in Umbrella applications

I do precise opposite. In apps/*/config.exs I only have:

use Mix.Config
import_config Path.join("..", "..", "..", "config", "config.exs")

and only have one instance of dev.exs, test.exs and prod.exs per whole project, instead of splitting this among multiple files.

It’s easier when the project becomes big to have the configuration consolidated in my opinion.

I prefer to keep app-specific config within their own directories. If I find that there is config that is common across multiple apps (ie. logger stuff), I will usually just create a new “logging” app that deals with all things logging. All the other apps then just add it as a dependency.

I delete these files at all, as apps/*/mix.exs already contain config_path: "../../config/config.exs" so all you need to do is to remove import_config "apps/*/config/config.exs" from root configuration and call it a day.

Yep, you can do that and it’s probably good for 99.9% of the cases. Leaving the files in allows you to handle the situation where app was started on it’s own, without other apps being started and give you the possibility to add some config option to handle that situation, but as I said it’s very rarely needed and your solution is good.

IMO the defaults clearly send the message of “have the bare minimum global configuration in the umbrella’s root config and put everything else in app-specific configs”. F.ex. the company’s brand name would go to the root config and be fetched from there instead of being copy-pasted in plain text in templates.

Perhaps the problem is that your current use case is not the same as this seemingly intended default?

But then it becomes more intense, ex. where should go logger configuration. Ok that is pretty simple, this is global configuration, so probably in root. But what when you are configuring metrics gathering? It should go to the top level or into application level? TBH I am more and more sure that configuration should be only global, and when you need to configure your application then you should put as much as possible configuration into compiler.app specs, so instead of having solution proposed by the Phoenix with :load_from_env set to true in config/prod.exs instead it should be:

def application do
  [
    # …
    env: [
      {MyAppWeb.Endpoint, load_from_env: true}
    ]
  ]
end

And then you can disable it in per-environment configuration. And apps/*/config directories should not exist at all, only global configuration. That would also encourage people to have sys.config as small as possible instead having enormous amount of cruft (often needed only in compile-time) there.

As mentioned above, you eliminate the need for all “global configuration”, which IMO, is less than ideal (ignoring the fact that mix config is global anyways ), by simply creating apps for those “global requirements” - ie. logging and metrics. My umbrella apps usually include both a logging and metrics app. These apps will do all the setup required for their domain. Any app that requires logging or metrics simply has to add [{:logging, in_umbrella: true}, {:metrics, in_umbrella: true}] to their deps. If your requirements for logging or metrics ever expand - you have an easy point in which to work on it. This becomes more pronounced if you ever need to add “sinks” for either logging or metrics that require runtime config. Having an app for these makes it very clear where that code would go.

Keeps things focused. Works for me. Might not for others…

But are you aware, that adding dependency has nothing to do with configuration? Configuration of the dependencies is always ignored (unless you use your own wrapper over Logger in logging, then maybe, but Logger application is still global). So this approach is even more confusing.

But are you aware, that adding dependency has nothing to do with configuration

Not exactly true. If I have a logging app that uses an external service, and it requires runtime config, adding it as a dependency ensures that that app is started and configured before any app that depends on it.

I’d also argue that in many ways, this approach can be seen as more simple. If you open up an umbrella app, and need to change something to do with logging - where would you go first? The global config? The per app config? Or the app named logging. In my mind - thats pretty clear.

TBH, I would go straight to global config, because you cannot configure Logger per application, both Erlang’s logger and Elixir’s Logger are global. I would somewhat agree if we would talk about metrics application, but logging for me is misleading.