Strongly Typed Configuration Access With Code Generation

Most config libraries use a stringly typed approach.

Some handle runtime failures due to invalid configuration schemas by leveraging data types like Option or Result to represent missing values or errors. This allows us to handle these failures by either providing default values or by providing decent error messages.

This is a good strategy that we should definitely stick to.

However, the problem with default values is that we might not even notice if the configuration is broken. This could potentially fail in production. In any case an error e.g. due to a misspelled config property will be observable at runtime at the earliest.

Wouldn’t it be a great user experience (for us developers) if the compiler told us if the configuration schema is invalid? Even better, imagine we could access the configuration data in a strongly typed way like any other data structure, and with autocompletion.

Moreover, what if we didn’t have to write any glue code, not even when the configuration schema changes?

This can be done with the costs of an initial setup that won’t take more than probably around 5 minutes.

Continue reading →