Quarkus – A convincing Framework

I have been developing applications using #java since release 1.0. I have gone through all the different enterprise releases starting Servlets and EJB 1.0 to now with #Java EE/#Jakarta EE.

In the last years the development of web applications have mostly shifted towards #Spring Boot. Spring Boot makes it easy to create stand-alone, production-grade Spring based Applications that you can "just run” but it also imposes an opinionated view of the Spring platform and third-party libraries so that anyone can get started with minimum fuss. Most Spring Boot applications need very little Spring configuration, this makes it easy to write maintainable code, or even better, it helps you to write maintainable code.

On the topic about maintainability, an architecture that supports writing highly maintainable software systems and is very much loved nowadays, is the #microservices architecture. The main reason being is that a distributed architecture allows to work in an isolated mode on “mini applications” those can be orchestrated to implement the required functionalities that end users expect from the system you are building. The work in isolation makes it easier to write more maintainable code. And of course you can also choose different languages and frameworks.

When looking to write microservices with Java, we have now several options, from the standard Java/Jakarta EE and Spring-Boot, to the more specifically microservice oriented frameworks such as Quarkus, Micronaut, or Helidon. But so far, beside some tutorials and a couple of home projects, I never had the possibility of using any one of these frameworks in real projects. But that changed in the past few months. I had the possibility to work on not one but two projects using Quarkus! Both projects were for the Canton of Wallis – a governmental unit in Switzerland.

First: what is Quarkus?

Quarkus is a Java open-source framework optimized to run on top of Kubernetes, tailored for OpenJDK Hotspot and GraalVM, crafted from best-of-breed Java libraries and standards.

A major improvement of Quarkus over traditional IoC frameworks is the evaluation of application context. Traditional reflection-based IoC frameworks, such as Java/Jakarta EE or Spring-Boot, load and cache reflection data of every bean in the application context during the start-up phase, impacting the start-up time and initial memory consumption of the application. Quarkus, on the other side, evaluates the reflection data of every bean in the application context at build-time and saves it with the generated code, massively improving the start-up time as well as the initial memory consumption, and it also validates all configuration properties. In the build-time phase Quarkus uses a technique called AOT (Ahead-of-Time) compilation, which results in smaller packages containing only the classes that are used by the application.

Bear in mind that not every feature is available in a native execution, the AOT compilation has its limitations. For instance, Reflection and Java Native Interface (JNI) will not work, at least out-of-the-box (requires some extra work).

How I and Quarkus became friends

As I mentioned above, I recently worked on two customer’s projects using Quarkus and had the chance to make my first experience with this framework. Of note is that for the customer Quarkus is the Java Framework of choice for all Java Projects, including the migration of older projects to Quarkus. The first project was for the development of a Web-Application style architecture with the front-end implemented in Angular and the back end with Quarkus JAX-RS Services, the second project was a batch processing style application. Both projects are deployed in a container environment using Red Hat OpenShift.

Project #1

A web application for the management of the documents used in the justice procedures by the different jurists and legal assistants involved. In addition, there was a module for the control of the financial assets of Foundations. For this project based on Quarkus version 1.13.8.

Principal extensions used:

• quarkus-resteasy: REST endpoint framework implementing JAX-RS and more
• quarkus-hibernate-orm: persistent model with JPA and Hibernate ORM
• quarkus-liquibase: database schema migrations with Liquibase
• quarkus-keycloak: control access to protected resources using Keycloak-managed permissions
• quarkus-smalrye-health: monitor service via Microprofile health

Project #2:

A batch processing application which is used for notifying interested people about published articles. The processing runs every five minutes and queries a news server using #GraphQL, if any news were published then the application is creating a newsletter with the title and summary of the news, post and schedule the newsletter on a Campaign site, and finally notifies the editors that the newsletter has been created. For this project is based on Quarkus version 2.4.2.

Principal extensions used:

• quarkus-rest-client: call REST services
• quarkus-qute: templating support for web, email, etc in a build time, type-safe way
• quarkus-mailer: send emails
• quarkus-scheduler: schedule jobs and tasks

As a developer, if you have been developing applications using Spring-Boot, REST, JPA stack then its super easy. You can build an application from scratch with the same effort. Quarkus has genuinely nice guides for getting started (https://quarkus.io/guides ). They also provide a similar launch-your-application feature like spring initializr, see http://code.quarkus.io .

And what else did I like about it?

It has a few things that, as a developer, are remarkably interesting. Besides the unified configuration, Quarkus is a very compact framework, and it comes with many integrations (via extensions) to many frameworks and libraries. I really like the fact that I do not need to depend on a certain IDE to write code and have this nice live reload for the application. But from version 2.0, the live reload applies also to the unit tests, by automatically running the tests that are associated with the code being modified, making TDD an amazingly easy integrated experience.

Just press r to enable it. Then open the Dev UI console, http://localhost:8080/q/dev. At the bottom of the page, you will find the panel responsible testing module. Just click the Test result icon and you will see a screen like the one below.

Secondly, what I liked about Quarkus is that it offers the same patterns that I am used with Spring. For instance, when working with persistence, using JPA with Hibernate, I like to use the repository pattern, which helps in abstracting the code, with Spring Data. Quarkus also implements the repository pattern with Panache, but, in addition, it adds the Active Record pattern (https://en.wikipedia.org/wiki/Active_record_pattern).

Finally, since I am also coming from the Spring world and its many modules. I appreciated the fact that Quarkus offers Spring API compatibility for part of the Spring modules. If you are familiar with Spring and you want to easily start to learn Quarkus, you can use the Spring API compatibility by lowering the learning curve. What Quarkus brings to this union is the fact that you benefit with early detection of dependency injection errors at compile time instead of at runtime.

As a remark, Quarkus is built to be familiar to developers coming from Java/Jakarta EE, meaning that its REST API is based on the Microprofile specifications, even if they are not fully implemented.

Sounds nice, but what challenges did we have?

For some Quarkus made some poor choices in some extensions or their defaults, for instance the connection pool for JDBC, JWT extension etc. But since it is truly modular and extension based, it is easier to remediate than with other architectures.

Some of the extensions are experimental. So, should we be afraid of that? We are engineers, our job is to find solutions! So no, I am not afraid of experiments, I am ready to evolve with them ...What I can say from my own experiences is that the need to make a few tweaks to use a specific version of a framework or library is a normal experience for every developer (See here for the list of available features).

If you are curious about using Quarkus, try to POC it first, or any of the examples that come with the Quarkus guides, and have a good base on what you plan to do with it, and not just start big because somebody said it is cool. Most important, you need to have some measurements and see how that works. The learning curve is quite easy. That is another thing that is surprisingly nice and good about Quarkus, it is amazingly easy to learn.

And finally, Quarkus can help in Green IT, which aims to minimize the negative impact of IT operations on the environment, i.e., less usage of resources disk space, memory, time (reducing costs, especially important for serverless). A Quarkus build results in smaller jars, Faster start-up time, and Low RAM usage.

Below are the comparison stats for start-up time and memory footprint of Quarkus packaging.

In conclusion, I really liked to work with Quarkus for this and this reason and I am looking forward to doing many more projects using Quarkus. In mine opinions the selling points for Quarkus are:

• A compact core and extensions, allowing for rapid expansion, which will nurture innovation
• High velocity development, with local and remote dev mode, and interactive unit testing
• Fast growing eco-system through the core extensions, the universe extensions (e.g., Camunda) and the Quarkiverse
• Good dev guides, allowing to quickly grasp the different facets of Quarkus
• A vivid community, which listens actively for feedback, and welcome contributions

All images have been taken from the project or the Quarkus Guide documents.