goth v1.2.0 Goth.Config behaviour
Goth.Config
is a GenServer
that holds the current configuration.
This configuration is loaded from one of four places:
- a JSON string passed in via your application's config
- a ENV variable passed in via your application's config
- The Application Default Credentials, as defined by https://developers.google.com/identity/protocols/application-default-credentials
- an
init/1
callback on a custom config module. This init function is passed the current config and must return an{:ok, config}
tuple
The Goth.Config
server exists mostly for other parts of your application
(or other libraries) to pull the current configuration state,
via Goth.Config.get/1
. If necessary, you can also set config values via
Goth.Config.set/2
Link to this section Summary
Functions
Returns a specification to start this module under a supervisor
Retrieve a value from the config
Invoked when the server is started. start_link/3
or start/3
will
block until it returns
Set a value in the config
Callbacks
A callback executed when the Goth.Config server starts
Link to this section Functions
add_config(config)
child_spec(init_arg)
Returns a specification to start this module under a supervisor.
See Supervisor
.
get(key)
Retrieve a value from the config.
get(account, key)
init(envs)
Invoked when the server is started. start_link/3
or start/3
will
block until it returns.
init_arg
is the argument term (second argument) passed to start_link/3
.
Returning {:ok, state}
will cause start_link/3
to return
{:ok, pid}
and the process to enter its loop.
Returning {:ok, state, timeout}
is similar to {:ok, state}
except handle_info(:timeout, state)
will be called after timeout
milliseconds if no messages are received within the timeout.
Returning {:ok, state, :hibernate}
is similar to {:ok, state}
except the process is hibernated before entering the loop. See
c:handle_call/3
for more information on hibernation.
Returning {:ok, state, {:continue, continue}}
is similar to
{:ok, state}
except that immediately after entering the loop
the c:handle_continue/2
callback will be invoked with the value
continue
as first argument.
Returning :ignore
will cause start_link/3
to return :ignore
and
the process will exit normally without entering the loop or calling
c:terminate/2
. If used when part of a supervision tree the parent
supervisor will not fail to start nor immediately try to restart the
GenServer
. The remainder of the supervision tree will be started
and so the GenServer
should not be required by other processes.
It can be started later with Supervisor.restart_child/2
as the child
specification is saved in the parent supervisor. The main use cases for
this are:
- The
GenServer
is disabled by configuration but might be enabled later. - An error occurred and it will be handled by a different mechanism than the
Supervisor
. Likely this approach involves callingSupervisor.restart_child/2
after a delay to attempt a restart.
Returning {:stop, reason}
will cause start_link/3
to return
{:error, reason}
and the process to exit with reason reason
without
entering the loop or calling c:terminate/2
.
Callback implementation for GenServer.init/1
.
map_config(config)
set(key, value)
Set a value in the config.
set(account, key, value)
start_link(envs)
Link to this section Callbacks
init(config) (optional)
A callback executed when the Goth.Config server starts.
The sole argument is the :goth
configuration as stored in the
application environment. It must return {:ok, keyword}
with the updated
list of configuration.
To have your module's init/1
callback called at startup, add your module
as the :config_module
in the application environment:
config :goth, config_module: MyConfig