# SpringBoot3 vs Quarkus ## Description Ce dépôt contient les APIs SpringBoot3 et Quarkus de l'application Norsys Inventory. Les deux APIs ont exactement le même fonctionnement. Le but est de comparer la version 3 de SpringBoot à Quarkus version 2 pour l'instant . Cette dernière ajoute la fonctionnalité de compilation native. Le but de ce projet et de comparer les performances et les ressources consommées avec les compilations native et JVM des applications. Ce depot contient 3 modules maven. ### domains Ce module represente le coeur metier de l'application. Dans ce module on y trouve l'implementation des diffrents objets que le projet utlise ### back-norsys-inventory-quarkus Ce module contient l'implementation de l'api avec le framework quarkus ### back-norsys-inventory-quarkus Ce module contient l'implementation de l'api avec le framework spring boot ## Usage ### Profils maven Il y a plusieurs profils sur l'application. Le profil `exclude-embedded-mongo` qui permet de désactiver la base de donnée embarqué pour les test lors du lancement de l'application. Il y'a aussi le profil `native` sur les projet. Ce profil permet de compiler l'application en mode native avec l'outil GraalVm ### Installation `mvn clean install` ### SpringBoot #### Compilation JVM mvn package #### Compilaion Native mvn -Pexclude-embedded-mongo,native spring-boot:process-aot #### Création de l'image docker mvn -Pexclude-embedded-mongo,native spring-boot:build-image ### Quarkus #### Compilation JVM mvn package #### Compilaion Native mvn install -Dnative ### Création de l'image docker mvn quarkus:image-build ## Comparaison Pour les comparaisons nous avons choisi pour l'instant 3 criteres : ### Temps de demarrage : ![](https://hackmd.io/_uploads/rks6_Mkdh.png) Les temps de demarrage sur la version native sont quasiment inconsiderable par rapport a la version JVM, ce qui explique l'interet de la version native qui est le lancement d'une application java sur moins de ressource et avec un temps de demarrage inconsiderable lors du deploiement des application. Avec l'autoscaling lors du deploiement d'applications on pourra lancer de multiple applicaation lors d'un pique de charge et pouvoir les supprimer quand y'a pas de charge sur l'application par contre l'application native prend beaucoub plus de temps pour créer les images native. POur les comparaison entre les deux framework on peut dire que quarkus se lance plus rapidement que spring boot . ### Ressources consommées ![](https://hackmd.io/_uploads/BkEEafyO2.png) (avec kubectl) Pour les ressources consommées par les applications nous avons pu mesurer le nombre de cpu utilisés et la memoire aussi. Comme l'image precedente le montre on deduit que les versions natives des deux framework consomment moins de ressource que les versions jvm ce qui explique que la version jvm a besoin de plus de ressource pour lancer la jvm hors la version native se lance directement et interagit directement avec le system d'exploitation. ### Temps de reponses sur des requetes http : ![](https://hackmd.io/_uploads/Hymq-1QO3.png) ![](https://hackmd.io/_uploads/HkU9bJXO3.png) (les graphiques son issus d'un scénario gatling) Pour les temps de réponse des API, on remarque une différence entre la JVM et la native, car au début du scénario, la JVM a un temps de réponse plus élevée. Cela peut s’expliquer, car La JVM effectue également des optimisations dynamiques pour améliorer les performances au fil du temps. Cela signifie que les performances peuvent s’améliorer à mesure que l’application s’exécute et que la JVM ajuste les paramètres. Aussi, La JVM utilise la compilation JIT (Just- in-Time) pour améliorer les performances de l’application. Le bytecode Java est compilé en code machine natif pendant l’exécution de l’application. Au début, les parties du code qui ne sont pas utilisées peuvent encore être en mode interprété, et elles seront compilées en code natif au fur et à mesure de leur utilisation. La native, quant à elle, compile tout d’un coup avec le procces AOT (Ahead-of-Time) ce qui explique le fait que les temps de réponse sont toujours faibles et constants. Mais l’optimisation de la JVM est efficace lors d’une grosse charge de l’application, car elle gère les réponses plus efficacement. La native aura beaucoup plus de mal et sera amenée à s’éteindre brusquement. # Points restants a traiter : - Implementer les diffrentes fontionnalitées autoriser seulement aux admins de l'application et diffrencier les operation sur les deux api entre les admins et les autre utilisateurs. - utilser Jackson views pour recuperer seulement les nom des produits sur l'endpoint catalog/products sur les 2 apis