Client-side bootstrap approaches

In the example solution described previously, all of the applications must hold the network location of the configuration server. The network location of service discovery is stored there as a property. At this point, we are confronted with an interesting problem to discuss. We could ask whether our microservices should be aware of the Config Server's network address. In previous discussions, we have agreed that the main place all the service’s network locations should be kept is the service discovery server. The configuration server is also a Spring Boot application like other microservices, so logically it should register itself with Eureka to enable the automated discovery mechanism for other services that have to fetch data from the Spring Cloud Config Server. This in turn requires placing the service discovery connection settings in bootstrap.yml instead of the spring.cloud.config.uri property.

Choosing between these two different approaches is one of the decisions you need to make while designing your system architecture. It's not that one solution is better than the other. The default behavior for any application that uses the spring-cloud-config-client artifact is called Config First Bootstrap in Spring Cloud nomenclature. When a config client starts up, it binds to the server and initializes the context with remote property sources. That approach has been presented in the first example in this chapter. In the second solution, the Config Server registers with the service discovery and all of the applications may use DiscoveryClient to locate it. That approach is called Discovery First Bootstrap. Let's implement an example that illustrates that concept.