Migrating a Spring app to a Quarkus app

Recently I've been looking at the potential of the serverless frameworks Quarkus and Micronaut. They look really promising, and therefore I tried to convert a Spring Boot service to a Quarkus service. In this blogpost you will find the actions that you have to take to do it yourself, and some noteable thing that I have learned in the process.

Build

First of all, Quarkus only supports Maven at this point. For Gradle a preview has been brought out, but if you're going for a production app, that's not the stable option you want to take. So if your Spring Boot app is currently built with Gradle, I'd suggest converting it to make use of Maven.

Database connection

Quarkus has hibernate to connect to a database with the needed database drivers like MySql, Postgress, H2 in-memory and so forth. The Quarkus team have provided an simplified implementation called "Panache". It works quite similar to the Spring JpaRepository works and it provides an extra way of accessing the data, called the Active Record Pattern. In a Spring to Quarkus migration you probably don't want to move to that solution.

For migrating a Spring repository to a Quarkus Panache repository you have to change a couple of things:

• Your Spring repository is an interface, in Quarkus it is a class
• Quarkus' Panache repository method names are different from Spring's repo
• All persisting methods need @Transaction to work when called

Spring repo:
public interface PersonRepository extends CrudRepository<Person, Long>

Quarkus repo:
public class PersonRepository implements PanacheRepository<Person>

Little extra note for those with an import.sql script in their SB application: The naming convention that Spring Boot has differs a bit from Quarkus' implementation when it comes to camelcase. Where the field paymentDate is converted to the sql field payment_date in Spring, it is converted to the sql field paymentDate in Quarkus. So keep in mind that you either change the fieldnames in your import.sql or add an hibernate property to change this behaviour.

Swagger

For the swagger documentation side of things, not much is needed. In Spring you've got yourself two dependencies generally: swagger and swagger UI. In Quarkus these two are combined in the package quarkus-smallrye-openapi. Besides that, no additional config is needed for basic usage. Include the dependency and access it at /swagger-ui. Note that this only works in dev mode. To use it on production you just add quarkus.swagger-ui.always-include=true in the property file.

Property files

Another notable thing is that your yaml configurations from Spring don't work out of the box; you are going to need an extra yaml-config dependency. Another big change are the property profile files. That does not exist at the moment in quarkus. If you want to have several profiles it is going to look like this:

quarkus.http.port=9090
%staging.quarkus.http.port=9999
%prod.quarkus.http.port=8080

Missing

Last but not least, Quarkus' age. The framework looks really promising and already has a good collection of extensions to make some cool stuff. However it looks like the developers aimed at quantity of extensions instead of the quality. I'm not saying they are bad, they are just far from complete or completely missing. A lot of features that you take for granted when using Spring are either in "preview", incomplete or simply missing. Therefore going to production with more complexity than simple REST endpoints is to me not a good idea yet. But I will surely be frequently playing with it and tracking its process and hoping that it will improve soon.