Spring Boot: Spring Cloud Config Client

[swarajsaaj]

1. In generator-jhipster, the Jhipster registry (https://github.com/jhipster/jhipster-registry) was shipped together. I think we can use the same (not just for config server, also for the eureka registry part). Any opinions for not using that and using https://hub.docker.com/r/springcloud/configserver instead?

2. As registry/consul and config-client usually are used with microservices, shall we group them under spring-boot/microservice umbrella? (e.g. spring-boot/microservice/config-client, spring-boot/microservice/registry/consul-client and spring-boot/microservice/registry/eureka-client ?

[swarajsaaj]

Instead of '/microservice, it can bespring-boot/spring-cloud/config-client` and in addition following approach:-

• [ ] Add config-client dependency
• [ ] Setup spring-cloud/config-client context
• [ ] Add jhipster-registry.yml in src/main/docker
• [ ] Add properties for connecting to config-client

[pascalgrimaud]

Look good to me, excepting there are 2 possibilities:

• jhipster registry as config server
• consul as config server

[swarajsaaj]

For consul as config provider (with 'spring-cloud-starter-consul-config'), it has pre-requisite that consul is in place already as using only config KV without registry capabilities is unusual. Can add the config as an option in Consul context. WDYT?

[pascalgrimaud]

Mhhh it's related to another ticket. Let's start with your 1st idea + jhipster registry, we'll see later for spring cloud consul

[pascalgrimaud]

@swarajsaaj : so I had a look and indeed you're right - see https://github.com/jhipster/generator-jhipster/blob/main/generators/server/templates/src/main/resources/config/application-dev.yml.ejs#L93-L114

There are 2 configs:

• spring.cloud.consul.config
• spring.cloud.config.uri

So this ticket should be related only to spring cloud config (not consul) I wonder if we should implement this ticket in the same context than Eureka ?

• API to generate Eureka + Spring Cloud Config
• API to generate only Spring Cloud Config

It means this ticket https://github.com/jhipster/jhipster-lite/issues/280 can only be done after this one. What do you think?

[swarajsaaj]

@pascalgrimaud :

So this ticket should be related only to spring cloud config (not consul)

Yes agreed, as I have seen projects using only config-server for dynamic configuration without need of eureka at all (like in kubernetes based deployments, where you may not need additional registry but dynamic configuration is required instead of configmaps)

The fact that jhipster-registry is a combination of both eureka and config-server, doesn't mean project would require both always, so I think to have two separate APIs for more flexibility:-

1. API to generate Eureka
2. API to generate only Spring Cloud Config

[pascalgrimaud]

thanks @swarajsaaj ! agree with you

[swarajsaaj]

thanks. will submit a PR today/tomorrow.