Wow this really made me think. Thank you for this strategy! I tried it and it works very well – the hex suggestion was helpful for study.
vrod
0
hauleth
There are basic 2 types of config in Elixir code:
- Compile time configuration. Before Elixir 1.10 you could call
Application.get_env/{2,3}in any part of the code, even compile time, so people often did stuff like:
This caused thedefmodule Foo do @option Application.get_env(:my_app, :foo_config) # … end@optionto be set during compilation, so if someone was using releases (Distillery or Relx at the time) could be confused why@optiondidn’t changed when the configuration was changed on the target server. Since 1.10 we haveApplication.compile_env/{2,3}andApplication.get_env/{2,3}will print warning when used in compile time. There are few examples of applications that use compile time env and in few situations this still sometimes makes some sense (for example poor-man dependency injection). - Runtime environment, that is
Application.get_env/{2,3}calls within functions body, that is it. The “funny” thing there is that runtime configuration is also divided in 2 separate things (and people often forgot about it):- “Startup config” that is read only at the beginning of application lifetime (often in module that is implementing
Applicationbehaviour, or ininit/1functions of the servers). This is for example reason why simpleApplication.put_env(:logger, :level, :warning)will not work, and you need to useLogger.configure(level: :warning)or reason why you cannot configure:kerneland:stdlibapplications viaconfig/config.exs(so for example configuration of Erlang’sloggeris currently enormous PITA in Elixir). - “On-demand” configuration where
Application.get_env/{2,3}is called “in-place”, where it is needed. Reason why a lot components cannot be configured that way are mainly 2:- Performance - reading environment is much slower than just variable from the process state
- Data is needed at the start of the process - for example you cannot change port on which Cowboy is listening for connections after it was started (obviously)
- “Startup config” that is read only at the beginning of application lifetime (often in module that is implementing
So 1. is obviously something that you cannot configure in runtime (examples of such behaviour is :mime database). And depending when your Vapor configuration will be ran 1.1. can also be off limits, at least for some applications (notably :kernel and :stdlib are hard to configure with any Elixir tooling).
5
vrod
Interesting, thank you! I am wondering can you clarify somethings?
Performance - reading environment is much slower than just variable from the process state
Is Application.get_env/3 reading from the process state?
How is configuration of Erlang’s logger PITA? (I am only familiar with basic log level setting)
0
hauleth
It is more like reading from ETS AFAIK. That is why it is not the best performance-wise when used in environment that need to be as fast as possible (like logger calls).
You cannot do stuff like:
config :kernel, :logger, [
# …
]
In your config/config.exs nor in config/runtime.exs as when these files are evaluated by Mix kernel application is already started and running. This mean that you cannot easily configure logger in development that will work from the beginning of the VM lifetime (like for example SASL startup messages).
Let just say, that this isn’t very popular approach in Elixir development to use Erlang’s logger to full extent, but with Elixir 1.11 it can became more and more feasible to do so, as Elixir backends do not have simple access to structured logging (it will always be translated to plain string) nor to all log levels (these have access to “basics” - debug/info/warn/error, while Elixir 1.11 supports all 7 syslog levels). There are PRs to OTP to improve that, but it will take some time before that functionality will be available in Elixir.
2
dch
The Application.env is 100% ets:
iex(serenity@wintermute.skunkwerks.at)9> :ets.tab2list :ac_tab
[
{{:application_master, :credentials_obfuscation}, #PID<0.367.0>},
{{:env, :gettext, :default_locale}, "en"},
{{:env, :kernel, :logger},
[
{:handler, :default, :logger_std_h,
%{
config: %{type: :standard_io},
formatter: {:logger_formatter,
%{legacy_header: true, single_line: false}}
}}
]},
{{:application_master, :cowboy}, #PID<0.415.0>},
{{:env, :amqp_client, :writer_gc_threshold}, 1000000000},
{{:env, :lager, :crash_log_count}, 5},
{{:env, :ex_unit, :timeout}, 60000},
{{:application_master, :goldrush}, #PID<0.326.0>},
{{:loaded, :logger},
...
You can look in the observer app, if you select view -> ETS tables -> system tables too.
For better (read-only) performance, look at persistent_term — OTP 29.0.2 (erts 17.0.2) the persistent term cache, added in OTP21.2. Note that updating this is a java-esque stop-the-world scenario for the entire VM.
- Clever use of persistent_term - Erlang/OTP
- Use :persistent_term for Logger config by josevalim · Pull Request #8977 · elixir-lang/elixir · GitHub where Elixir starts using PT for Logger app
4