A Spring Cloud Application Outline

While still in the early stages of our NixMash Spring Cloud application it's a good time to outline the moving parts before the app gets too complex. In this post we will simply display the pieces that comprise a Spring Cloud application. In future posts we will get into the how's and why's of those pieces.

The best way to introduce yourself to a Spring Cloud application is Josh Long's Cloud Native Workshop Code on GitHub as well as viewing one of his Spring Native Java with Spring Boot and Cloud presentations on YouTube.

Project Structure

The modules that currently comprise our Cloud Application are shown in this IntelliJ Project View. The CONFIG module is our Cloud Config Server. EUREKA is used for Service registery and discovery. CORE is a small module with shared Containers, Enums and such used by NixMash Cloud Services and Clients. POSTS is our Posts Service and MVC is our Web Client.

Cloud Config Server Property Files

In a Spring Cloud app we have a Cloud Config Server which our services and clients look to for configuration information. The Config Server has a Git Config Directory to house those settings. Here is the NixMash Cloud Config Server directory. (If you're looking for the directory on GitHub you'll find it here.)

The location of the Cloud Config directory is set in the CONFIG Module's application.properties file.


Each Service and Client has a bootstrap.properties file which replaces their normal application.properties file and must contain the following two properties: 1) URI address of the Config Server, and 2) Their Spring Application Name. Here's the bootstrap.properties file of the POSTS Service Module.

Note that http://localhost:8888 is the Spring Cloud Config Server default address so it didn't have to be listed. Also note that the post-service Application Name corresponds to the Config Server post-service.properties file name.

Cloud Config Server Properties In Action

The role of the Spring Cloud Config directory is to centralize the management of the Cloud App. For an example of centralized settings, here is the post-service.properties file with a simple message property.

When the Posts Service starts up and hits the CommandRunner, ${message} is retrieved from the Cloud Config Server post-service.properties file, or "Greetings from Vermont!"

A good tip on Config Directory property handling (or any changes) is to remember that the directory is a GIT directory so to put any updates into affect the directory will have to be staged/commited in Git.

Eureka Service Registry and Discovery

Eureka plays a big part in tying together the various parts of a Spring Cloud Application. Spring Cloud supports other registry-type services other than Eureka, but Eureka is an integral part of Netflix Cloud Services and very popular. Using a Service Registry app like Eureka means we don't have to rely on DNS locations for services, among other benefits. When we load the Eureka Service page we find our MVC Client and POSTS Service.

Annotations, Annotations

Here's a quick glance at the essential Spring Annotations with each piece of the Cloud Application, starting with the CONFIG Cloud Server Module.

EUREKA Discovery and Registry Service

POSTS Service

And finally, the MVC Client Module.

The Role of REST

The POSTS Service delivers Posts in REST format. No Service Methods required, just a PostRepository class annotated with @RepositoryRestResource to get up and running. The REST output for Posts from the Service at http://localhost:8000/posts looks like this. Notice the _embedded Resource Label.

But what's with the http://localhost:8001/post-service/posts URL? That's actually the Client EDGE location, a proxy for the Posts Service itself. Josh Long does a good job in his Cloud Native presentations on that topic.

Retrieving Data From the Post Service

There are a number of ways to retrieve data from a Microservice in Spring. One way is to create a Feign Client Binder to our Posts Service HTTP API Endpoints. Here we create the Client Interface. Behind the scenes we are finding the Posts Service Endpoint from our Eureka registry and delegating it to the proper services through the underlying Ribbon load balancer.

We then use the PostReader Component in our MVC Client Controller to create a List<Post> attribute.

Data Just Like Any Other

The final result is a list of Posts from our Posts Service displayed on our MVC Client Home Page just like any other list of Posts.

Source Code Notes for this Post

Source code discussed in our Spring Cloud Series is found in NixMash Spring Cloud on GitHub. Code for this particular post is found in branch nixmashcloud-v0.1.0 – Initial Layout and Structure.