On April 16 I attended our PanCompany-internal meetup on Quarkus, hosted by my colleagues Tonny Vos and Yuri Vrancken. This is my report on the evening.

After the introduction, those present were asked about their experience in other (microprofile) frameworks. Within PanCompany we can conclude that we are currently mainly experienced in JEE and Spring boot. Some of us use other frameworks like Vert.x or Micronaut.

Quarkus?

So what is Quarkus and why would you go about and use it? If we look at the goal of Quarkus it is to “make Java a leading platform in Kubernetes and serverless environments while offering developers a unified reactive and imperative programming model to optimally address a wider range of distributed application architectures.” A very noble and gargantuan goal, if you ask me.

In its foundation, Quarkus (web) uses Vert.X / Netty, Undertow, JAX-RS and Reactive Routers. Besides these technologies it also consists of the Quarkus Core and ArC (Quarkus dependency injection). Reasons to use Quarkus according to Quarkus are (but not limited to): Container First, Unification of imperative and reactive programming, Developer Joy and Best of Breed (using Standards)

Tonny added: it’s Developer Friendly, performing, lightweight, has ‘Extensions’ and if you are to go for Native Images first or are to migrate from JEE to a microprofile landschape, he would advise to start using Quarkus since much of JEE is (easily) ports towards Quarkus.

If we look at some statistics from Github we see that (at the time of the meetup) that Quarkus has a lot of traction. For example, it has 7.4K stars comparing it to the 4.8K of Micronaut or the 12K of Vert.X, it has 468 contributors and made 12 releases already in 2021. One can conclude that the community behind Quarkus is quite active. These numbers are impressive when compared to the older frameworks that of course have more contributions accumulated over time.

Demos!

Now that we went through the basics, it was time for some code. Yuri started by showing us how easy it is to set up a small REST-API endpoint. After that he showed us what one of the main strengths (developer friendly) was all about, ‘hot code reload’. When developing, we as developers are often confronted with the fact that we need to wait until the application is started again. Depending on the size of your project and the actual change you made, this can be(come) quite frustrating. Quarkus helps you in a quite ingenious way by doing the reloading for you without you even noticing. This can be achieved by running the code in ‘dev-mode’.

As developers we also work a lot with data and DSM (domain specific models) and the mapping between them. Most of the time we use some sort of ORM (Object-relation mapping) for this. Quarkus has its own extension for this (with a pretty cool name if you ask me) called Panache. After seeing some code examples, what struck me is that the code used is far less than I am used to when using the Mongo Client for Vert.x.

Pitfalls

So, is everything honky-dory and smooth sailing then? Is it possible to just start and migrate everything towards Quarkus? Well first, that depends on the size of your app and second: no … there are pitfalls when moving from JEE to Quarkus for instance.

Tonny took us through some code and based on his own experience, some of the challenges we could encounter. One of the challenges that comes to mind right away is that when using (your own) libraries that have beans that should be injected and picked up by the CDI you need to specify a beans.xml even though the content of the file is ignored. What on the other hand was really cool was that there is a property (quarkus.index-dependency) that can be used in your ‘application.properties’ so you can easily configure what environment uses stub versus production services. This also works when testing your application.

One other challenge is that when comparing Quarkus to Spring or Vert.x the amount of ‘out of the box’ libraries (Extensions) are a bit behind, and you might end up having to write your own library.

Testing

Speaking of testing, as our last topic, Tonny showed us how to test an app using Quarkus. Using the QuarkusTest annotation you can test your HTTP endpoints using the RESTassured testing framework. When running as a QuarkusTest you are also using Mockito, helping you focus on what you would like to test instead of worrying about the at that time non-essential services.

Outro

One of Quarkus’ strengths if you ask me is that it is really fast in starting up (even more so in native!) and the amount of code needed is less than I’m used to.

After all the demo’s, I for one am very excited to start using it in personal projects at first and maybe later weigh if we should not change certain parts from Vert.x to Quarkus. After working with Vert.x for a while I can see that some things that Quarkus does is way more practical in a sense to what I have become accustomed to. I would advise everyone who (haven’t) heard about Quarkus to at least read about it and put it on your ‘check it our’ list.

Danny de Vlam

PS: Check out our Gitlab group for code.