After years in the Spring ecosystem, I’ve moved over to the Java EE side of the world. I started working with Red Hat in April and as an application services solution architect, I work with many different customers running mostly Java EE stack.
That being said, prior to joining Red Hat, I had started to use their new runtime, Quarkus, to build some side projects. I’ve really enjoyed not only the ease of use of the runtime, but also getting back into the traditional Java EE CDI world and the Microprofile.
Lately, I’ve been building quite a few REST APIs using Quarkus for demos to customers. Along the way, I’ve gotten to know many of the Quarkus extensions and have come up with a good list of the standard extensions any REST API project will need.
Core Extensions
After initilizing a new project using the Quarkus plugin for Intellij, I immediately go in and start getting the POM in order and adding in the extensions.
Yaml Configuration
Yaml has a love/hate thing with developers, but since I spend most of my time building container based applications for OpenShift, the Red Hat enterprise Kubernetes offering, I spend much of my day in the yaml world. Quarkus has an option to manage it’s application config using yaml. The greatest benefit to this is reduction of text.
<dependency>
<groupId>io.quarkus</groupId>
<artifactId>quarkus-config-yaml</artifactId>
</dependency>
And now your config is yaml. First thing is to turn the banner off. 🙂
quarkus:
banner:
enabled: false
REST Extensions
resteasy-jackson
Quarkus uses resteasy for its rest implementation. However, I am a big fan of using Jackson for json serialization so I drop in the resteasy-jackson extension.
<dependency>
<groupId>io.quarkus</groupId>
<artifactId>quarkus-resteasy-jackson</artifactId>
</dependency>
The resteasy-jackson extension indirectly references the quarkus-resteasy extension, so if you add this, you can remove the explicit dependency on the other.
OpenAPI
The OpenAPI project is the defacto-standard now for documenting your REST APIs. The out of the box swagger generation, as well as the “demo this” api UI is very powerful. It’s a must have.
<dependency>
<groupId>io.quarkus</groupId>
<artifactId>quarkus-smallrye-openapi</artifactId>
</dependency>
Health and Metrics
Quarkus makes it stupid-easy to drop in both health and metrics endpoints, which are must haves for Kubernetes control plane and any Prometheus based metrics gathering.
<dependency>
<groupId>io.quarkus</groupId>
<artifactId>quarkus-smallrye-metrics</artifactId>
</dependency>
<dependency>
<groupId>io.quarkus</groupId>
<artifactId>quarkus-smallrye-health</artifactId>
</dependency>
Testing Extensions
Testcontainers
Check out my post regarding local integration testing. Testcontainers is a huge win for doing integration testing not only locally, but within the CI pipeline. Add this to the dependencyManagement group.
<dependency>
<groupId>org.testcontainers</groupId>
<artifactId>testcontainers-bom</artifactId>
<version>1.14.3</version>
<type>pom</type>
<scope>import</scope>
</dependency>
Then you can add the different container types to the dependencies.
<dependency>
<groupId>org.testcontainers</groupId>
<artifactId>junit-jupiter</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.testcontainers</groupId>
<artifactId>kafka</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.testcontainers</groupId>
<artifactId>postgresql</artifactId>
<scope>test</scope>
</dependency>
Assert/J
I love fluent assertions. Assert/J is referenced by the BOM so adding it with its managed version is easy.
<dependency>
<groupId>org.assertj</groupId>
<artifactId>assertj-core</artifactId>
<scope>test</scope>
</dependency>
Database Extensions
If you are persisting data to a database, then the Panache extension is a great way to do it. Personally, I think it’s a more concise and easier to understand model then the spring-data project and really gives a lot of bang for the buck.
Combine it with Flyway for schema management and it’s almost cheating.
<dependency>
<groupId>io.quarkus</groupId>
<artifactId>quarkus-hibernate-orm-panache</artifactId>
</dependency>
<dependency>
<groupId>io.quarkus</groupId>
<artifactId>quarkus-jdbc-postgresql</artifactId>
</dependency>
<dependency>
<groupId>io.quarkus</groupId>
<artifactId>quarkus-flyway</artifactId>
</dependency>
Container Builds
Quarkus can even manage publishing your containers to the image repo.
<dependency>
<groupId>io.quarkus</groupId>
<artifactId>quarkus-container-image-docker</artifactId>
</dependency>
Then in the config, you add the following info and it’ll push the image after build.
quarkus:
container-image:
registry: quay.io
group: kubetrade