YAML is a human-friendly notation used in configuration files. Why would we prefer this data serialization over the properties file in Spring Boot? Besides readability and reduction of repetition, YAML is the perfect language to write Configuration as Code for the deployments.
In the same way, the use of YAML for Spring DevOps facilitates the storage of the configuration variables in the environment as the 12 Factor Authenticator recommends.
In this tutorial, we’ll compare Spring YAML versus properties file in order to check the main advantages of using one over the other. But remember, the selection of YAML over properties file configuration is sometimes a decision of personal taste.
2. YAML Notation
YAML stands for a recursive acronym for “YAML Ain’t Markup Language“. It provides the following characteristics:
- More clarity and human-friendliness
- Perfect for hierarchical configuration data
- It supports enhance capabilities such as maps, lists, and scalar types
Those capabilities make YAML the perfect companion for Spring configuration files. A word of caution here for those starting out with YAML: writing it can be a bit tedious at the beginning due to its indentation rules.
Let’s see how it works!
3. Spring YAML Configuration
As it was mentioned in the previous sections, YAML is an extraordinary data format for configuration files. It’s much more readable, and it provides enhanced capabilities over the properties file. Therefore, it makes sense to recommend this notation over the properties file configuration. Furthermore, from version 1.2, YAML is a superset of JSON.
In addition, in Spring the configuration files placed outside the artifact override those inside the packaged jar. Another interesting feature of Spring configuration is the possibility to assign environment variables at runtime. This is extremely important for DevOps deployments.
Spring profiles allow separating the environments and apply different properties to them. YAML adds the possibility to include several profiles in the same file.
Note: this feature is also supported for properties files with Spring Boot 2.4.0.
In our case, for deployment purposes, we’ll have three: testing, development, and production:
Note: if we use a Spring Boot version prior to 2.4.0, we should use the spring.profiles property instead of the spring.config.activate.on-profile we used here.
Let’s now check the spring.profiles.active property which assigns the test environment by default. We can redeploy the artifact using different profiles without building again the source code.
Another interesting feature in Spring is that you can enable the profile via the environment variable:
We’ll see the relevance of this environment variable in the Testing section. Finally, we can configure YAML properties assigning directly the value from the environment:
We can see that if no environment variable is configured, a default value dev-YAML is used.
4. Reduction of Repetition and Readability
The hierarchical structure of YAML provides ways of reducing the upper levels of the configuration properties file. Let’s see the differences with an example:
this should be a long
this should be another long
The same configuration would become redundant using properties file:
component.idm.description=this should be a long \
component.service.description=this should be another long \
The hierarchical nature of YAML greatly enhances legibility. It is not only a question of avoiding repetitions but also the indentation, well used, perfectly describes what the configuration is about and what is for. With YAML, as in the case of properties file with a backslash \, it is possible to break the content into multiple lines with > character.
5. Lists and Maps
We can configure lists and maps using YAML and properties file.
There are two ways to assign values and store them in a list:
external: [www.abc.test.com, www.xyz.test.com]
Both examples provide the same result. The equivalent configuration using properties file would be more difficult to read:
Again YAML version is more human-readable and clear.
In the same way, we can configure maps:
Now, let’s check if everything is working as expected. If we check the logging of the application, we can see that the environment selected by default is testing:
2020-06-11 13:58:28.846 INFO 10720 --- [main] com.baeldung.yaml.MyApplication: ...
Description: this should be a long description
Description: this should be another long description
We can overwrite the name by configuring DEV_NAME in the environment:
We can see that the name of the environment changes executing the application with dev profile:
2020-06-11 17:00:45.459 INFO 19636 --- [main] com.baeldung.yaml.MyApplication: ...
Let’s run for the production environment using SPRING_PROFILES_ACTIVE=prod:
2020-06-11 17:03:33.074 INFO 20716 --- [main] ...
In this tutorial, we described the intricacies of the use of YAML configuration compared to the properties file.
We showed that YAML provides human friendliness capabilities, it reduces repetition and is more concise than its properties file variant.
As always, the code is available over on GitHub.