Déjà, merci d'avoir jeté un oeil à Quarkus. Ca fait plaisir d'en entendre parler par ici :). J'avais hésité plusieurs fois à faire un journal, il me semble que j'avais même commencé à en rédiger un et puis c'est tombé dans l'oubli.
Ensuite, même si Quarkus a été marketé pour les micro-services au départ, tu peux parfaitement construire des bonnes grosses applications. Personnellement, je suis un fervent défenseur du cas d'usage de la "boring app", la bonne vieille application de gestion toute bête qui fait le taf.
Après, je te concède que cette limite est pénible, je jetterai un oeil à ton générateur, merci de l'avoir partagé. Je sais qu'on a une limite côté ArC qui peut poser souci au niveau du nombre de classes qui sont des beans CDI. On en a parlé plusieurs fois, je pense qu'il faut qu'on travaille pour la lever.
Ca ne concerne pas tant d'applications que ça, mais j'aimerais autant qu'on soit aussi généraliste que possible. Avoir des limites arbitraires, même élevées, c'est relou.
Pour la compilation native, oui, ça demande des ressources assez élevées si l'application est grosse au point de devenir assez inutilisable. Ce n'est pas un cas d'usage où je conseillerais la compilation native.
Je ferais un peu de profiling de la phase de construction avec ton exemple parce que ça me semble assez intéressant de regarder s'il y a des endroits où on peut réduire le temps de construction de l'application. Merci d'avoir partagé le générateur et merci de le laisser où il est, ça va nous être utile :).
Si jamais tu veux échanger plus avant, je suis joignable à guillaume point smet à gmail point com et je suis toujours ravi d'échanger sur le sujet.
# Merci !
Posté par Guillaume Smet (site web personnel) . En réponse au lien Quarkus, Spring Boot et les monolithes : Peut-on moderniser un projet géant sans tout casser ?. Évalué à 5.
Hello,
Déjà, merci d'avoir jeté un oeil à Quarkus. Ca fait plaisir d'en entendre parler par ici :). J'avais hésité plusieurs fois à faire un journal, il me semble que j'avais même commencé à en rédiger un et puis c'est tombé dans l'oubli.
Ensuite, même si Quarkus a été marketé pour les micro-services au départ, tu peux parfaitement construire des bonnes grosses applications. Personnellement, je suis un fervent défenseur du cas d'usage de la "boring app", la bonne vieille application de gestion toute bête qui fait le taf.
Après, je te concède que cette limite est pénible, je jetterai un oeil à ton générateur, merci de l'avoir partagé. Je sais qu'on a une limite côté ArC qui peut poser souci au niveau du nombre de classes qui sont des beans CDI. On en a parlé plusieurs fois, je pense qu'il faut qu'on travaille pour la lever.
Ca ne concerne pas tant d'applications que ça, mais j'aimerais autant qu'on soit aussi généraliste que possible. Avoir des limites arbitraires, même élevées, c'est relou.
Pour la compilation native, oui, ça demande des ressources assez élevées si l'application est grosse au point de devenir assez inutilisable. Ce n'est pas un cas d'usage où je conseillerais la compilation native.
Je ferais un peu de profiling de la phase de construction avec ton exemple parce que ça me semble assez intéressant de regarder s'il y a des endroits où on peut réduire le temps de construction de l'application. Merci d'avoir partagé le générateur et merci de le laisser où il est, ça va nous être utile :).
Si jamais tu veux échanger plus avant, je suis joignable à guillaume point smet à gmail point com et je suis toujours ravi d'échanger sur le sujet.