--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "lescastcodeurs".
Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.
Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msgid/lescastcodeurs/81763e93-1942-438b-80b8-4ea631505665n%40googlegroups.com.
From: "Henri Tremblay" <henri.t...@gmail.com>
To: "lescastcodeurs" <lescast...@googlegroups.com>
Sent: Monday, October 16, 2023 3:22:04 AM
Subject: Re: [LCC] Spring reactor et virtual threads
Ma réponse à moi:Je n'ai jamais aimé la complexité ajoutée par Spring Reactor et tout au framework de programmation non-bloquante.Il faut vraiment avoir d'énormes besoins de performance pour en avoir besoin.
Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msgid/lescastcodeurs/CADZL2%3Dukb9H1f2PhWJotKDPp-nq2Dv1QFsowDWgTN0vmK_RqhA%40mail.gmail.com.
Il y a aussi le cas du streaming, le cas original pour lequel Netflix
a developpé ce qui est devenu reactor. Netflix avait une architecture backend en deux couches avec la première couche agrégeant les données de plusieurs micro services de la seconde couche. Récemment ils ont remplacé la première couche qui faisait de l'agregation de donnée avec reactor par du GraphQL fédéré [1]. Donc au lieu d'avoir plein de services spécifique qui save faire l'agregation de donnée spécifique pour lequel on a besoin d'une librarie reactive, ils ont un seul service qui fait de l'aggregation GraphQL.
--RémiEt oui, je pense que les virtual threads, structured scope, scoped values vont changer la donne, car on arrive enfin à quelque chose de très lisible tout en ayant de belles performances.--On Fri, 13 Oct 2023 at 07:56, Daniel Teixeira <ddt...@gmail.com> wrote:Bonjour,Merci pour parler des virtual threads en Java 21!--J'aimerai savoir quel est votre avis par rapport à Spring Reactor et l'arrivée des virtual threads en Java 21.Dans notre entreprise Spring Reactor est devenu la norme et tout doit être fait avec de la programmation réactive et je m'inquiète quant à maintenabilité du code. Le code devient plus compliqué à développer, debugguer et tester. Et je me demande si cela ne rajouterait pas une dette technique majeur au lieu d'en retirer. Des simples conditions avec 2 ou 3 IFs et un try catch, deviennent quelques chose d'infernal avec des map, flatMap, whenEmpty, etc.... le code peut devenir vraiment facilement compliqué à lire et comprendre.. Personnellement j'ai l'impression qu'on a tendance à "overuser" de la technologique sans qu'il y aie vraiment besoin de l'utiliser (application utilisée en interne, avec des utilisateurs limités, non exposée sur internet). Je comprends l'intérêt quand on a des millions d'utilisateurs mais avec une quantité limitée d'utilisateur j'ai mes doutes.Surtout avec l'arrivée des virtual threads est-ce que cela fait encore du sens de faire de la programmation réactive, étant donné que les threads ne resteront plus bloqués?Merci pour votre retour,Daniel
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "lescastcodeurs".
Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.
Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msgid/lescastcodeurs/81763e93-1942-438b-80b8-4ea631505665n%40googlegroups.com.
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "lescastcodeurs".
Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.
Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msgid/lescastcodeurs/CADZL2%3Dukb9H1f2PhWJotKDPp-nq2Dv1QFsowDWgTN0vmK_RqhA%40mail.gmail.com.
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "lescastcodeurs".
Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.
Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msgid/lescastcodeurs/287272987.24881594.1697436740371.JavaMail.zimbra%40univ-eiffel.fr.
From: "Alexandre Bertails" <alex...@bertails.org>
To: "lescastcodeurs" <lescast...@googlegroups.com>
Sent: Monday, October 16, 2023 9:12:17 PM
Subject: Re: [LCC] Spring reactor et virtual threads
Il y a aussi le cas du streaming, le cas original pour lequel Netflix"Streaming" dans la présentation de Paul désigne les systèmes pour le service Netflix lui-même, par opposition à "Enterprise", qui adopte aussi le même type d'architecture, mais c'est plus récent.a developpé ce qui est devenu reactor. Netflix avait une architecture backend en deux couches avec la première couche agrégeant les données de plusieurs micro services de la seconde couche. Récemment ils ont remplacé la première couche qui faisait de l'agregation de donnée avec reactor par du GraphQL fédéré [1]. Donc au lieu d'avoir plein de services spécifique qui save faire l'agregation de donnée spécifique pour lequel on a besoin d'une librarie reactive, ils ont un seul service qui fait de l'aggregation GraphQL.Ce dont Paul parle dans sa présentation est que l'évolution de l'architecture vers Falcor puis GraphQL a grandement réduit le besoin d'écrire du custom code qui a besoin d'orchestrer des appels concurrents vers plusieurs microservices, vu que c'est en grande partie géré et standardisé par la GraphQL Federated Gateway. Bref, GraphQL et Reactor ne sont pas du tout en opposition, d'ailleurs le DGS framework s'intègre en fait très bien avec Reactor, et j'utilise cette combinaison tous les jours.
Les virtual threads c'est cool, je pense que ça va aider dans les cas les plus simples, mais pas vraiment pour les cas plus avancés où on a besoin d'être précis sur comment composer des services complexes, ou si on a besoin de constructions de plus haut niveau pour gérer des problèmes de back pressure, etc.
Alexandre
Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msgid/lescastcodeurs/CANvn8kwAnLn-Tnjha9gnmJ6gcObxHFmjdwGSQdNDNiN22tMj_A%40mail.gmail.com.