Nous développons beaucoup de solutions en interne pour des besoins client ou nos besoins internes. En fonction des caractéristiques de chaque projet, nous sommes amenés à faire des choix technologiques et quelques solutions sont développées en Java à l’aide de framework relativement connus, voyons-voir lesquels nous utilisons
Quels framework(s) ?
Nous utilisons principalement deux framework Java, l’un des plus connus : Spring Boot et le petit “nouveau” Micronaut. Nous utilisons principalement Spring Boot pour nos besoins orientés purement métier, sans forcément besoin de performance avancée. Micronaut est plutôt utilisé dès lors que nous avons des contraintes de développement de micro-services dits “critiques”.
Spring Boot
Spring Boot est un mastodont et l’un des plus utilisés en Java. Ce framework est stable et nous permet d’adresser facilement beaucoup de problématiques. Son support natif de beaucoup de technologies (ElasticSearch, MongoDB, GraphQL, MySQL, Cache Redis, RabbitMQ et autres) en fait de lui une boite à outils agréables à utiliser mais il est conçu d’une façon qui en fait de lui un consommateur de mémoire et un temps de démarrage par défaut assez grand (Tout cela peut être amélioré avec Spring Boot 3.0 et son support de l’AOT / GraalVM)
Une fois le projet compilé, il est très facile à déployer puisque le serveur Web est intégré. Ceci est pratique pour ne pas maintenir un serveur Web à part entière et obtenir des mises à jour régulières grâce à son intégration.
Micronaut
Dès lors que nous sommes dans un contexte où nous souhaitons obtenir un temps de démarrage très court (par exemple quand on fait du serverless avec notamment de l’appel de cloud functions ou FAAS … functions as a service), une consommation de mémoire optimisée, nous privilégions Micronaut.
Micronaut est un framework relativement jeune (cela ne veut pas dire qu’il n’est pas stable) mais partant d’un paradigme assez simple : faire à la compilation, le plus tôt possible, ce qui peut être massivement fait pour ne faire au runtime que ce qui est vraiment nécessaire. Par exemple, tout ce qui est réflexion est déléguée à la compilation et n’est plus fait à chaque appel au runtime. Cela a pour conséquence des économies de mémoire et un peu plus de vélocité.
