Example of a microservice that works on Spring Boot.
- Java 8
To make setting up microservices in micro-time we needed to extract the common building blocks to separate libraries. In this template we are using the following 4finance custom libraries (available in jcenter)
You can remove all the caching related libraries, annotations and com.ofg.twitter packages. Next adjust all the properties and then you have an empty project - you're now ready to go.
Below you can find description of the most crucial parts of the application's production code.
contains Spring Boot autoconfiguration and contains main method
Spring boot auto-configure application and enable support for 4finance's "Micro Infra Spring". That enables module like ServiceDiscovery, Swagger, CorrelationId filters, custom RestTemplate, custom exception handling, health check controllers etc. Check out Micro Infra Spring's Boot Starter module's Spring factories set up
If you want only certain modules of the system just check out 4finance's Micro Infra Spring's readme.
Below you can find description of the most crucial parts of the application's test code.
extends com.ofg.infrastructure.base.IntegrationSpec Spock Specification class that initializes Spring web-context.
extends com.ofg.infrastructure.base.MvcIntegrationSpec Spock Specification class that initializes Spring web-context and provides some autowired fields including the ServiceProvider interface that allows you to stub Zookeeper entries.
extends com.ofg.infrastructure.base.MvcWiremockIntegrationSpec Spock Specification class that extends the MvcIntegrationSpec spec. Additionally it provides WireMock related fields and methods.
you may wonder - how on earth does the collaborator collerator respond to with 200 when you post him at /1 ?! It's all about Consumer Driven Contracts and our implementation called stub-runner-spring.
What happens under the hood is that the stubs are downloaded from 4finance Bintray account. A jar of the stub-runner-examples is downloaded and unpacked to a temporary folder and all the tests are ran against it. The stub is in fact here twitter-places-collerator stub!
The paths to the repo, the module name and artifactId are here - application.properties.
Twitter places analyzer, searches through tweets for places. Then analyzers send those to Collerators.
Hit PUT at:
/api/{pairId}
with list of tweets:
[
{
"created_at": "Sat Jul 26 09:15:10 +0000 2014",
"id": 492961315070439424,
"id_str": "492961315070439424",
"geo": null,
"coordinates":
{
"coordinates":
[
-75.14310264,
40.05701649
],
"type":"Point"
},
},
{
"created_at": "Sat Jul 26 09:15:10 +0000 2014",
"id": 492961315070439424,
"id_str": "492961315070439424",
"geo": null,
"coordinates":
{
"coordinates":
[
-75.14310264,
40.05701649
],
"type":"Point"
},
}
]
And it will hit collectors at /{pairId} with tweets taken from twitter
[
{
"pair_id" : 1,
"tweet_id" : "492967299297845248",
"place" :
{
"name":"Washington",
"country_code": "US"
},
"probability" : "2",
"origin" : "twitter_place_section"
},
{
"pair_id" : 2,
"tweet_id" : "123187246819263981"
},
]