Creating a Microservice With Quarkus, Kotlin, and Gradle
A closer look at creating microservices on the modern JVM frameworks: Quarkus, Kotlin, and Gradle. Learn about the processes and technologies.
Join the DZone community and get the full member experience.Join For Free
In the previous article, the brief explanations of creating microservices on the modern JVM frameworks and comparison of them were shown. Now it’s time to take a closer look at the most recently appeared framework: Quarkus. I’ll describe the process of creating a microservice using the mentioned technologies and in accordance with the requirements specified in the main article.
You may also like: Build a Java REST API With Quarkus
This microservice will be a part of the following microservice architecture:
As usual, the project’s source code is available on GitHub.
In this project, Gradle Kotlin DSL as a build tool is used. A build script should contain:
Listing 1. build.gradle.kts
Plugins' versions resolution is performed in
DependenciesListing 2. build.gradle.kts
Also, it is needed to make some Kotlin classes open (they’re final by default; more details on Gradle configuration in the Quarkus Kotlin guide):Listing 3. build.gradle.kts.
The framework supports configuration via properties or YAML files (more detailed in the Quarkus config guide).
The configuration file is located in the
resources folder and looks like:
Here application’s standard properties are defined, as well as custom. Latter can be read as follows:Listing 5. Reading properties ( source code).
Before we start with the coding part, it should be noted that there is no main method in the source code of your Quarkus application, but maybe somewhen it will be.
@ConfigProperties bean from the previous listing to another bean is performed using
@ConfigPropertiesbean ( source code)
Listing 7. Injection of
ApplicationInfoService bean annotated with
@ApplicationScoped can then be injected itself like this:
@ApplicationScopedbean ( source code)
More on Contexts and Dependency Injection in the Quarkus CDI guide.
REST controller looks very typical for those who are familiar with Spring or Java EE:Listing 8. REST controller ( source code).
For working in a microservice architecture Quarkus service should be able to perform requests to other services. Since every service has the same API, it is worth to create a uniform interface for common code, and then a bunch of REST clients extending that interface:Listing 9. REST clients ( source code).
As you can see, creating REST clients to the other services is as simple as creating an interface using the proper JAX-RS and MicroProfile annotations.
As you saw in the previous section for the
baseUri parameter services' names are used. But now there is no built-in support of Service Discovery (Eureka) or it doesn’t work properly (Consul) because the framework mainly targets cloud environments. I’ve implemented Service Discovery using Consul Client for Java library. Consul client includes two necessary functions,
getServiceInstance (which uses the Round-robin algorithm):
At first, it is needed to register the application:Listing 11. Registration in Consul ( source code).
Then it is needed to resolve services' names to its particular location. For that, a class that extends
ClientRequestFilter and annotated with
@Provider was created:
The resolution is implemented simply by replacement URI of
requestContext object with a service’s location obtained from the Consul client.
Tests for both API’s endpoints are implemented using REST Assured library:Listing 13. Tests ( source code).
While testing, it is not necessary to register application in Consul, so I just put
ConsulClientMock that extends actual
ConsulClient next to the test class:
ConsulClient( source code)
build Gradle task
quarkusBuild task is being called. By default, it generates runner JAR and
lib directory with all the dependencies. To produce uber-JAR artifact
quarkusBuild task needs to be configured as follows:
To build project run
./gradlew clean build in the project’s root folder.
Before launching the microservice, you need to start Consul (described in the main article).
You can start microservices:
Execute in the project’s root folder:
Or call the task from IDE.
Using the uber-JAR.
Execute in the project’s root folder:
java -jar quarkus-service/build/quarkus-service-1.0.0-runner.jar
Now you can use REST API, for example, perform the following request:
It will return:Listing 16. API’s response.
In this article, we saw how to implement a simple REST service on Quarkus using Kotlin and Gradle. If you look at the main article, you’ll see that created application has comparable parameters to the applications on the other new JVM frameworks. The framework has serious competitors such as Helidon MicroProfile, Micronaut, and Spring Boot (if we speak about full-stack frameworks). Therefore I think that we are waiting for an interesting development of events that will be useful for the whole Java ecosystem.
P.S. Thanks to VLSI for helping with this article.
Published at DZone with permission of Roman Kudryashov. See the original article here.
Opinions expressed by DZone contributors are their own.