The Pip.Services Toolkit offers a simple but very flexible mechanism for component configuration. Configurations can be loaded from various sources - configuration files, command line parameters, environment variables, configuration services, etc. Once loaded, they are passed to the specific component, which configures itself accordingly. In this recipe, we’ll be taking a look at this mechanism’s capabilities and how it can be utilized.
A component can be made configurable by adding the IConfigurable interface and implementing its configure method. This method will be called by the container right after container creation, with the loaded configuration being passed as a parameter.
The only parameter that is passed to the configure method is ConfigParams object. Simply put - this is a map that allows us to get a configuration parameter value by its corresponding key. Although various programming languages have unique syntax for initializing maps and objects, ConfigParams support initialization that is independent of the language being used.
ConfigParams also provide some additional functionality. All keys and values are stored as strings, but ConfigParams supports performing data type conversion when extracting values. Another option available is the opportunity to set default values.
The parameter kets can have a complex structure, grouped by sections using dot notation. ConfigParams can be used to work with entire sections as well.
Lastly - ConfigParams objects can be serialized/deserialized to/from JSON, YAML, or a plain string.
To read more about what functionality is available through ConfigParams, be sure to check out the Commons module’s documentation.
Below is an example of a configurable component:
Manual configuration can be done in the following manner:
However, a component’s configuration is usually stored in the microservice’s configuration file. The configure method will receive the parameters for the specific component (in the example below - everything between the component’s descriptor and the next descriptor or end of the file). To get more info on microservice configuration, read our Component Container recipe.
The NameResolver and OptionResolver classes are helper classes that simplify the use of configurations.
NameResolver is a helper class that allows extraction of the component’s name from the configuration parameters. The name can be stored as a "id"/"name" parameter or inside a component’s descriptor.
Below is a simple example of how it can be used:
OptionResolver is a helper class that extracts parameters from the "options" configuration section.
Configuration parameters can be stored in microservice configurations, configuration files, or in configuration services. To help with configuration extraction, the Pip.Services Toolkit offers two special ConfigReader components. The interface for these components is defined in the Components module.
The MemoryConfigReader is a Config Reader that stores configuration data in memory.
The JsonConfigReader is a Config Reader that can read configurations from a JSON file.
The YamlConfigReader is a Config Reader that can read configurations from a YAML file.