Global state on startup

Phoenix Forum Questions / Help
1

Hey! I’m really enjoying getting into Elixir / Phoenix, but!

In my application, I would like to fetch some configuration from a JSON file when the app starts up and then have that configuration globally available in the Phoenix app. I have a lib module with a function which gets the configuration data and I can call that from my Phoenix application’s ex file, but I’m not sure where to put the result (or even if it’s a good idea). Thoughts?

Thanks,
Brian

2

The normal place for this sort of configuration would be config/config.exs or some other .exs file loaded by it. In other words, using configuration formats other than just ordinary Elixir code is generally discouraged.

That said, if you for some reason absolutely need to accept JSON configuration files specifically, the best place would still probably be something in or around config/config.exs. You’d probably need to define that function there, then call it with whatever arguments needed to load your JSON config. The resulting map (or whatever internal format used after parsing) could then be assigned to a configuration key for your OTP app.

For example (note the anonymous function in a variable; you can probably define a module in here, but whatever):

# config.exs
json_loader = fn(path) -> do_the_needful end

config :my_app, json_config: json_loader.("some_file.json")
1 Like
3

For an app I have, I wrote a GenServer that manages my preferences. It’s pretty simple, so it might not meet your needs. It loads up a prefs.json file at startup (you have to include it in your list of supervised children in your main application module.)

The app depends upon the ExActor GenServer helper as well as the Poison JSON library. You’ll have to add them as dependencies if you’d like to use the code, which you’re welcome to.

You can call into the module like so:
MyApp.Service.PrefsManager.get_value(“size”)
MyApp.Service.PrefsManager.set_value(“size”, 20)

defmodule MyApp.Service.PrefsManager do
  use ExActor.GenServer, export: PrefsManager
  require Logger

  defstruct prefs: %{}

  @prefs_path "prefs.json"
  defstart start_link do
    prefs = load_prefs()
    Process.flag(:trap_exit, true)
    initial_state(%__MODULE__{prefs: prefs})
  end

  def terminate(reason, state) do
    save_prefs(state)
    :normal
  end

  defcall get_value(key), state: state do
    prefs = state.prefs
    value = prefs[key]
    reply(value)
  end

  defcall set_value(key, value), state: state do
    prefs = state.prefs
    prefs = Map.put(prefs, key, value)
    state = Map.put(state, :prefs, prefs)
    set_and_reply(state, :ok)
  end

  defcall dump_prefs(), state: state do
    prefs = state.prefs
    reply(prefs)
  end

  defp save_prefs(state) do
    {:ok, string} = Poison.encode(state.prefs)
    File.write!(@prefs_path, string)
  end

  defp load_prefs() do
    case File.read @prefs_path do
      {:error, _error} -> %{}
      {:ok, json} ->
        {:ok, decoded} = Poison.decode json
        decoded
    end
  end
end
4

@YellowApple Thanks! I think I didn’t explain what I was doing well enough. I’ve definitely got some configuration variables in config/config.exs. They are github_token and repo_path. The idea of the app is that it will be able to receive webhooks from GitHub for certain events, so I go to the GitHub repo and get a json file from the root which has configuration for the behaviors on how to handle the webhooks. After your response it occurs to me that I might be able to have the configuration in config/config.exs, but my concern was being able to put the configuration into a place / format that it would be easy for anybody to update. Thinking on it further, it actually probably makes sense anyway to get the configuration each time. Part of the plan would also be to pull Markdown files from the repo as well which would contain text which would be used as part of the webhooks. It doesn’t really make sense to store the configuration globally anyway because it should always be using the latest copy.

@crusso Thanks, I had read about using processes to store ongoing state, so I might play with that as a solution