Managing configuration in Erlang application

Question

I need to distribute some sort of static configuration through my application. What is the best practice to do that?

I see three options:

1. Call application:get_env directly whenever a module requires to get configuration value.
   • Plus: simpler than other options.
   • Minus: how to test such modules without bringing the whole application thing up?
   • Minus: how to start certain module with different configuration (if required)?
2. Pass the configuration (retrieved from application:get_env), to application modules during start-up.
   • Plus: modules are easier to test, you can start them with different configuration.
   • Minus: lot of boilerplate code. Changing the configuration format requires fixing several places.
3. Hold the configuration inside separate configuration process.
   • Plus: more-or-less type-safe approch. Easier to track where certain parameter is used and change those places.
   • Minus: need to bring up configuration process before running the modules.
   • Minus: how to start certain module with different configuration (if required)?

Answer 1

Another approach is to transform your configuration data into an Erlang source module that makes the configuration data available through exports. Then you can change the configuration at any time in a running system by simply loading a new version of the configuration module.

Answer 2

For static configuration in my own projects, I like option (1). I'll show you the steps I take to access a configuration parameter called max_widgets in an application called factory.

First, we'll create a module called factory_env which contains the following:

-define(APPLICATION, factory).

get_env(Key, Default) ->
    case application:get_env(?APPLICATION, Key) of
        {ok, Value} -> Value;
        undefined -> Default
    end.

set_env(Key, Value) ->
    application:set_env(?APPLICATION, Key, Value).

Next, in a module that needs to read max_widgets we'll define a macro like the following:

-define(MAX_WIDGETS, factory_env:get_env(max_widgets, 1000)).

There are a few nice things about this approach:

• Because we used application:set_env/3 and application:get_env/2, we don't actually need to start the factory application in order to have our tests pass.
• max_widgets gets a default value, so our code will still work even if the parameter isn't defined.
• A second module could use a different default value for max_widgets.

Finally, when we are ready to deploy, we'll put a sys.config file in our priv directory and load it with -config priv/sys.config during startup. This allows us to change configuration parameters on a per-node basis if desired. This cleanly separates configuration from code - e.g. we don't need to make another commit in order to change max_widgets to 500.

Answer 3

You could use a process (a gen_server maybe?) to store your configuration parameters in its state. It should expose a get/set interface. If a value hasn't been explicitly set, it should retrieve a default value.

-export([get/1, set/2]).

...

get(Param) ->
  gen_server:call(?MODULE, {get, Param}).

...

handle_call({get, Param}, _From, State) ->
  case lookup(Param, State#state.params) of
    undefined ->
      application:get_env(...);
    Value ->
      {ok, Value}
  end.

...

You could then easily mockup this module in your tests. It will also be easy to update the process with some new configuration at run-time.

You could use pattern matching and tuples to associate different configuration parameters to different modules:

set({ModuleName, ParamName}, Value) ->
  ...

get({ModuleName, ParamName}) ->
  ...

Put the process under a supervision tree, so it's started before all the other processes which are going to need the configuration.

Oh, I'm glad nobody suggested parametrized modules so far :)