Migration Spring Boot vers Quarkus : retour d'expérience

Dans cet article, on va discuter d’une véritable migration d’un projet Spring Boot vers Quarkus ! On l'a testé pour vous, voici notre retour d'expérience.

Quarkus c’est un peu le super projet à la mode Java qui permet de réaliser des projets compilés en natif et donc capables de démarrer en instantané dans des conteneurs.

Pour en savoir plus, on vous encourage à écouter notre interview de Laurent Broudoux, CloudLe Cloud consiste à accéder à des ressources informatiques, à partir d'internet, via un fournisseur.-native AppDev Solution Architect chez Red Hat, c'est par ici !

Migration Spring Boot vers Quarkus : c'est parti !

Fort de notre envie de tester sur un vrai projet, nous avons pris un projet en production (certes pas le plus gros de notre projet, on n’est pas si fou que ça :)) et on a tenté de le migrer sur Quarkus. L’objectif était de vraiment se passer complètement de Spring, donc cela nous a valu de devoir réécrire des choses…

Le projet initial

Le projet initial est un Spring BootFramework Java se basant sur Spring. avec une dizaine de ws RESTREST (REpresentational State Transfer) est un style d'architecture logicielle qui fonctionne sous un certain nombre de contraintes., une dizaine d’entités, des appels SOAPSOAP (Simple Object Access Protocol) est un protocole de communication. à des services externes, une authentification OAuth2 (AzureAzure est la plateforme de Cloud de Microsoft. ad) ainsi que du stockage sur Azure, et un petit Flyway pour la gestion de la base de données, une petite PostgreSQLMoteur de gestion de base de données libre de droit.. Cette petite APIUne API est un programme permettant à deux applications distinctes de communiquer entre elles et d’échanger des données. est utilisée par un front AngularAngular est un framework de développement JavaScript populaire basé sur TypeScript.. Tout ce qu'il y a de plus classique !

Notre retour d'expérience

Sans suspense : nous avons réussi à le faire ! Et dans un temps globalement acceptable, environ 3 jours. Sachant que nous étions novices, nous pourrions aller beaucoup plus vite à présent !

Parlons un peu de la migration :

Nous avons pris le parti de démarrer depuis le projet Spring (compilé en Gradle) et de petit à petit le convertir en un projet Quarkus. Cette approche nous a paru plus simple que de partir d’un projet Quarkus vide et d’y mettre les classes. À l’expérience, je ne suis pas sûr que nous ayons gagné du temps, car cela nous a engendré pas mal de conflits de lib que nous aurions pu nous épargner.

Partons du début et essayons d’expliquer ce que nous avons changé :

• Les entités : nous n’avons absolument rien eu à changer !
• Les repository : plus complexe, mais pas non plus dur. Nous les avons remplacés par des PanacheRepository. Ça marche bien, mais nous avons dû réécrire les @Query en de vraies méthodes de classe. Nous avons néanmoins pu garder les query sans les réécrire, juste la manière de les appeler est différente. Dans ce projet, nous avions 10 repository, nous l’avons donc fait facilement, mais sur un gros projet, ça peut vite devenir fastidieux.
• Les services. Peu de changements. Il faut changer les annotations en particulier les @Autowired en @Inject et adapter quand il a été nécessaire les retours de méthodes des repository.
• Les restController par contre, c’est un peu plus de travail. Il faut remplacer toutes les annotations et comme elles n’ont pas exactement les mêmes paramètres, cela nécessite de faire pas mal de copier-coller assez pénibles. Pour autant, nous n’avons pas bloqué plus que ça.
• L’authentification nous a posé bien plus de problèmes ! En effet, la lib pour faire de l’OAuth2 sur Quarkus n’est pas compatible avec l’Azure ad qui il semblerait ne mette pas à disposition le bon endpoint. Nous avons donc dû passer sur OIDC ce qui nous a valu pas mal de galères pour trouver les bons paramètres. J’imagine que c’est un peu toujours le cas avec les authentifications ! Pour le coup, nous avons dû passer pas mal de temps pour réussir à faire fonctionner l’équivalent de ce que nous avions avant en particulier sur la récupération des rôles qui chez nous sont dans la base de données et pas dans l’authentification OIDC. Par chance, nous n’avons rien eu à changer côté front, le token JWT OAuth2 généré dans le front Angular est compatible.
• Flyway a marché du premier coup, sans trop de problèmes ! C’est un bon point, car cette lib est vraiment indispensable à mes yeux
• Les WS Soap… Ça a été bien plus compliqué de les faire fonctionner. Nous avons dû après moult tentatives, régénérer les clients WS à partir du WSDL. En effet, nous avions utilisé massivement les lib Spring pour le faire avant. En régénérant les clients avec Apache CXF, cela a fini par marcher. Je vous passe les problèmes entre Jakarta.xml et Java.xml qui m’ont bien agacé...
• Dernier petit problème est la sérialisation des JSON qui n’est pas exactement la même en particulier sur les dates que nous avons dû adapter.

Voilà à peu près ce que nous avons mis en oeuvre. Mais maintenant que c’est fait, c’est un vrai plaisir d’avoir une application qui démarre en instantané ! Pour le coup, la promesse est bien tenue. En plus dans notre cas cette API n’est pas utilisé souvent donc ça prend tout son sens.

Pour discuter migration de projet, n'hésitez pas à nous contacter !