Configuration

resources/application.yml

Related configuration values should be grouped under a common prefix and exposed through a dedicated configuration class. Annotate the class with @Configuration and @ConfigurationProperties, then inject it wherever the configuration values are required. For example, configuration values with the eva prefix should be accessable through an EvaConfig class. Injecting individual configuration values with the @Value annotation should be avoided. When adding new configuration values, extend existing prefixes where appropriate. Domain-specific configuration values should be placed under the subato prefix and be exposed through the SubatoConfig class.

Rich Templates

Some content may need to be configurable while retaining a rich format. For example, the backend provides a static Markdown file at resources/static/help.md, which serves as the body template for the help page rendered by clients. These templates may define placeholders in the format ${VARIABLE} and can be rendered with the StringTemplateEngine class. Then, the rendered markdown templates can be converted to plain HTML for allowing clients to display them.

ConfigController and PublicConfig

Clients may need to display selected configuration values or request rendered templates, such as the help.md template describes previously. For these scenarios, there is a ConfigController which defines various endpoints for clients to query. One of these endpoints (/config) serves a PublicConfig object, which contains configuration values that may be exposed to clients, such as the maximum allowed file-upload size.