Configuration sources
Last updated
Was this helpful?
Last updated
Was this helpful?
Configuration sources fetch data from storage (local files or remote APIs) and convert it to settings nodes, abstracting away actual data formats such as JSON or YAML.
They are not meant to be consumed directly and should be used in conjunction with a configuration provider (see assign sources to types and obtain settings from provider scenarios).
Sources are also responsible for data change detection. They expose a reactive interface with subscription support:
On each update, triggered either periodically or by an internal event, the source emits a pair: (settings, null) on success or (null, error) on failure. It's not required to deduplicate settings or errors at this level, although it's never wrong to do so.
Sources must never block indefinitely while waiting for data and should rather publish null settings after a short initial timeout.
Sources must be thread-safe and should be designed to support multiple concurrent observers. It is also expected that every new observer would immediately receive a notification with current state upon subscription.
Here are some of the often used source implementations:
It's also possible to implement a custom source.