Quarkus is an increasingly popular “container-first” Java framework by RedHat. Similarly to Spring Boot, there is no application server, but the server is part of your generated artifact. The first integration examples with Vaadin and Quarkus were written by Sven Ruppert early in the 0.x phase and some of our customers are already running their production systems on a Quarkus-based architecture.
However, we recently pushed out “official support”, meaning a simplified “getting started” experience, a built-in Jandex index, support for the slightly non-standard CDI, and integration tests, which we run on each and every build.
This Monday, I joined Quarkus Insights to discuss Vaadin integration and also the recent improvements, but we somehow ended up talking mostly about Vaadin itself for the whole hour, so I decided to write about my recent experiences with Quarkus and some enhancements that we have made for the integration.
I have recently worked on a couple of Vaadin example apps that I converted from Java EE to Quarkus. Based on those trials, I can definitely say that we are ready for prime time with this combination. I’m particularly impressed by the development mode of Quarkus. The Quarkus community also refer to it as “live reload”, but in Vaadin lingo it would be more like “hot swap”. On code changes, the JVM is updated so fast that I actually didn’t bring in either of my good friends, JRebel and HotSwapAgent.
A thing I have been missing from my usual setup with Spring Boot is the “Vaadin-style live reload”, which actually refreshes my browser when I hit save in the IDE. So you need to go to the browser and separately hit CTRL-R to see the changes. An obstacle in this area has been the lack of support for the WebSocket communication channel, which is required by our live reload and development mode. Some nice progress in that area was recently made by the Flow team’s newest member, Marco Collovati. So, yes, proper WebSocket-based push support for Quarkus will be out soon. For development mode browser live reload, we’d still need a hook into Quarkus internals.
Push support also helps us to clean up the integration examples so as to look less hacky, as we can now rely on default servlet registration without the need to disable the development mode gizmo. Another element that further simplifies the integration is a new module, vaadin-quarkus-extension, which brings in a couple of dependencies that Vaadin users needed to set up separately. It also paves the way for further integration with Quarkus tooling, so that it would be easier to add Vaadin into an existing Quarkus project.
I also played a while with native compilation. While we don’t provide the “reflection hints” that would make that procedure much easier, it certainly is doable. I have another write-up about native binaries coming up but, for the most eager ones, there is a “native-image” branch in the starter repository.
Have you already tried out Quarkus with Vaadin? What would be your next favorite feature? Discuss it – we’ll listen!