Right, or to make a wider point here: if a library is starting a server during its boot, then that server is by default singleton, and the library should provide its name. What’s the point of that name being configurable?
Now, what you probably wanted to point out is that some libraries do require some options during their boot. I definitely agree that providing parameters, such as log level, which is needed during dependency’s (in this case Logger) startup, must be done via config scripts.
However, as we now both agree, that’s not the case for e.g. pubsub name, so it’s a matter of judgement. The reason I’m poking on this property is because Phoenix generator (phx.new) includes it by default in app env, together with a bunch of other stuff which is IMO not configuration, at least not by default.
So I’m still unsure why is pubsub name a configuration, nor how does such configuration gives us loosely coupled components (the claim stated by @michalmuskala)?
The pubsub name is provided by client code, which is of course a good thing, because we can have multiple pubsubs. I’m wondering why this name has to exist in config.exs? What’s the difference between this name, and say a registry name, which we usually provide as a function parameter. Why is pubsub name a “configuration”, and registry name isn’t?
A broader question: what is a configuration? What’s the criteria for providing some parameters via config.exs vs just using functions?
For all my years of programming in at least 8 languages and no less than 30 frameworks the only ever meaningful answer to this question for me was…
Because it is easier to consolidate in a single file.
Sometimes there’s a secondary answer which is “this is really important to setup on boot and isn’t expected to change” but that’s tangential and not directly related. I would argue that this “configuration” centralization is useful because library defaults could sometimes conflict with your own code artifacts (imagine if you were oblivious of configuration and figured your app needs the exact same hierarchy of options that ecto needs – as a random example).
How would you answer your own question, by the way?
But what exactly is being consolidated? Some pieces of data go to config scripts, while others are provided through regular code. So config scripts do not really contain all the parameters of our system, not even all parameters we pass to external libs.
I have no answer to that question. Config scripts seem quite arbitrary to me. A bunch of unrelated data is stuffed together for the reasons which I can’t fathom.
I would say “the bizarre artifacts of your current tech” which in the case of Erlang & Elixir would be app names, different environments (dev / test / prod). And I am probably forgetting a few more.
I would venture to say that everything outside of these really should be function parameters or module attributes.
However, in his blog post about mocks Jose gives a really good example for a Twitter client implementation that should vary between environments. But yeah, that depends on the tech’s peculiarities, in this case different environments.
So would you agree that only your tech stack’s specifics should be a subject to the current incarnation of configuration in Elixir?
I’ve argued at lengths in my recent post that IMO most of the data stashed in config scripts doesn’t really belong there. I think that the only viable reason for putting something in a config script is if a library requires it during it’s boot (e.g. Logger config), or during compilation (which I think is a really bad pattern).
I believe that in most other cases we’d be better off if we consolidated the data by their purpose (e.g. provide all endpoint parameters in the endpoint module, and all repo parameters in the repo module).
So I definitely agree that there are legacy reasons for stashing data in config scripts. However, I also think that generators, such as mix phx.new store too much data there, and by extension inspire other developers to overuse config scripts. I feel that this excessive usage of config scripts is the main cause of the problems people experience with Elixir configuration.
Agreed 100%. I haven’t been responsible for deploying to prod but I observed and listened to people doing it and like you, also found most configurations to be really out of place.
Nailed it. The problem then becomes, should all these modules have mandated locations? Say, lib/boot/<library_boot_module>.ex, maybe? And if it’s not mandated, wouldn’t people just splatter all that information all over the place and make the situation even harder?
EDIT: Just remembered about Rails’ config/initializers/ paradigma. It seems like a decent idea to duplicate in Elixir, don’t you think?
What about situations where your config may come from an external source like etcd or a database? Would you then make each of those modules responsible for talking to an external service to get their config? How would you handle a library you didn’t own needing that config?
I feel like this sort of situation warrants a centralized place to get config. Because otherwise you make each of the configurable apps responsible for knowing how to get their configuration.
I personally think they shouldn’t. In most cases, a library should take it’s parameters as function args (or return value of callback functions), and not enforce how this data is provided.
I would argue that using config scripts is splattering the data all over the place. For example, consider endpoint parameters which are by default sitting in four config scripts (config.exs, dev.exs, test.exs, prod.exs), but the ultimate source of truth is still endpoint module, where in init/2 that config data is further enhanced. Wouldn’t it be more consolidated if you listed all the endpoint parameters in init/2?
It’s been a really long time since I’ve worked with Rails, but my memories of its configuration and initializers are not good memories I prefer an explicit mechanism which fits well with the standard way of writing Elixir code. We already have that for our applications, and I think we could have the same for booting of the entire system.
Just call something like EtcdClient.fetch(...) or Database.fetch(...)?
In a simple scenario, there could be a wrapper module for fetching stuff from the configuration storage. Let’s call it EtcdConfig. Then other modules, such as endpoint and repo call the functions from such module.
In a more complicated scenario, you might want to cache these parameters, maybe periodically refresh them. In such cases, I’d use a dedicated ETS table (but not app env), and the implementation would become more complex, involving a couple of processes. But still, from the client’s perspective things would be simple, as client modules would just call well defined functions from the module responsible for fetching the data.
That depends on how the library accepts values.
If it accepts them as function parameters, or callback function return values, then it’s as simple as ExternalLib.some_fun(fetch_value_from_wherever(...)).
If it requires app env value but not during its boot, then it’s more complicated, but it can be handled during the client app’s start/2 callback.
If the library requires app env value during its boot, then currently we have no good solution, and need to resort to various kind of trickery.
You lost me here. What sort of situation warrants a centralized place, what would such place be, and what belongs to the config to begin with? This words gets thrown around a lot, but I haven’t seen anyone explaining when some piece of data is consider a “config”, instead of just plain function argument.
I prefer an explicit mechanism which fits well with the standard way of writing Elixir code. We already have that for our applications, and I think we could have the same for booting of the entire system.