Quarkus est défini comme un framework Java natif pour Kubernetes. Il fonctionne sur une JVM, mais aussi en natif. Il fonctionne avec les outils, les librairies et frameworks communs du monde Java. Il a été conçu pour les développeurs pour faciliter sa prise en main.

Quoi de mieux qu’un retour terrain d’un développeur utilisant Quarkus ? Lucas Declercq, développeur logiciel chez INEAT, a répondu à nos questions.

Comment t’es-tu intéressé au projet Quarkus ?

J’ai découvert Quarkus dans l’épisode 206 du podcast les CastCodeurs, où Emmanuel Bernard (qui fait partie des cast codeurs, mais qui est aussi le responsable du projet Quarkus chez Red Hat) présentait quarkus après avoir bossé dessus en secret pendant plusieurs mois. J’ai tout de suite accroché au concept et j’ai suivi le projet via la mailing-list depuis, c’est assez impressionnant de voir l’évolution en moins de deux ans. Dans le cadre de mon travail, j’ai la chance de travailler depuis 9 mois sur un projet (architecture microservices, event driven) basé sur Quarkus. Tout le monde n’y était pas convaincu d’utiliser une techno aussi "jeune", mais on ne l’a jamais regretté depuis.

On présente souvent Quarkus comme un compagnon idéal des développeurs Java dans le monde conteneur ? Tu en penses quoi ?

Je dirais qu’il y a deux grandes raisons pour ça : 

- d’une part du fait de la faible empreinte mémoire et du démarrage rapide (même en JVM), Quarkus est idéal pour une utilisation conteneurisée sur une infra partagée (Kubernetes, voire serverless)

- d’autre part, l’équipe de quarkus a vraiment mis l’accent sur l’outillage lié aux conteneurs : utilisation de l’api Kubernetes, endpoints de readiness/liveness, multiples manières de créer un conteneur (maven, jib, dockerfile), développement serverless

Est-ce que Quarkus a apporté un réel boost pour utiliser les applications Java et les piles techniques Java dans le monde Cloud ?

Les piles techniques souffraient depuis quelques années de la comparaison avec d’autres comme nodejs, notamment sur la légèreté, le temps de lancement, facilités pour le développeur (comme le live reload), mais aussi (et surtout) c’était moins "hype". Des frameworks comme Micronaut et Quarkus remettent Java sur le devant de la scène en ciblant les éléments que je viens de citer. D’autre part, je pense que l’approche de Quarkus de se baser sur des librairies connues (CDI, Jaxrs, hibernate, etc.) tout en offrant de nouvelles API très agréables à utiliser est vraiment un plus. On diminue le risque partant sur du connu et du stable tout en apportant de l’innovation.

Comment intégrer Quarkus à son projet Java ? Faut-il partir d’un nouveau projet ou est-il possible de l’implémenter dans un projet existant ?

Pour ma part, je suis toujours parti d’un nouveau projet, mais il est possible de migrer un projet existant facilement dans deux cas :

- Si on vient du monde Spring, quarkus supporte en vrac les librairies suivantes de Spring : spring di, spring web, spring security, spring jpa, spring cache, spring scheduled, spring cloud config

- Si on vient du monde JEE, il y a beaucoup d’APIs communes avec Quarkus (cdi, jaxrs, persistence) ce qui facilite la transition.  Cela peut être plus ou moins facile en fonction du projet, je sais par exemple que les annotations de cycle de vie des EJB (@PostConstruct par exemple) ne sont pas supportées et qu’il faut les transposer en Quarkus.

Pour démarrer un nouveau projet quarkus, la page du starter est une des plus ergonomiques que j’ai utilisée : possibilité de pousser directement le projet sur GitHub, génération d’un exemple de code par rapport aux extensions choisies.

Faut-il un environnement / des piles particulières ou Quarkus est suffisamment souple ?

Cela dépend de si on veut utiliser Quarkus en mode JVM ou natif :

- En mode JVM rien de particulier par rapport à une application java classique

- En mode natif, il faut soit rester cantonné aux extensions quarkus (qui couvrent la majorité des besoins classiques), soit dans le cas où il est nécessaire d’utiliser une librairie pas supportée ; prier pour qu’elle n’utilise pas de réflexion. Dans ce cas, il y a un risque de passer énormément de temps à la rendre utilisable.

Quels conseils tu pourrais donner ? Des points particuliers à surveiller ?

Quand on débute avec Quarkus, je pense qu’il est important de se rendre compte que la plupart des fonctionnalités de Quarkus sont basées sur des outils existants, notamment beaucoup de choses viennent  du projet Smallrye. En effet, même si la documentation de Quarkus est vraiment bien faite, pour trouver des éléments plus précis il faut aller voir la documentation de ces projets "upstream". Par exemple la documentation de Smallrye Config est beaucoup plus détaillée que la doc de quarkus. Ça aide vraiment à voir tout ce qu’il est possible de faire avec les différentes APIs.

Je conseillerais aussi de ne pas hésiter à demander de l’aide sur la Mailing-List ou le chat Zulip, les développeurs du projet sont très réactifs en plus d’être sympathiques :)

Enjoy !