Spring reactor et virtual threads

34 views
Skip to first unread message

Daniel Teixeira

unread,
Oct 13, 2023, 7:56:57 AM10/13/23
to lescastcodeurs
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

Henri Tremblay

unread,
Oct 15, 2023, 9:22:19 PM10/15/23
to lescast...@googlegroups.com
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.

Et 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.

--
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.

Remi Forax

unread,
Oct 16, 2023, 2:12:30 AM10/16/23
to lescastcodeurs
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.

Je serais plus précis sur la notion de performance, pour un serveur web, il y a plusieurs mesures, une mesure est le temps moyen de traitement d'une requète, une autre est le temps pire cas de traitement d'une requète.
Les libraries reactive ou les threads virtuelles améliore le second temps mais pas le premier qui est lui plus souvent lié au traitement spécifique et/ou à la base de donnée.
Donc si on a pas beaucoup de requètes par seconde, utiliser une librarie reactive/des threads virtuelles sert à rien.

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émi

Alexandre Bertails

unread,
Oct 16, 2023, 3:12:31 PM10/16/23
to lescast...@googlegroups.com
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

 


Rémi


Et 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.

Remi Forax

unread,
Oct 16, 2023, 5:48:38 PM10/16/23
to lescastcodeurs
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

Bonsoir Alexandre,


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.

C'est pas en opposition avec Reactor lui même. L'idée derrière DGS est de faire de la composition de données et pas de la composition de services. Si tu fais pas de la composition de services, ton API riche de composition de services a beaucoup moins d'intéret.


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.


Pour une API synchrone, la back-pressure se fait en utlisant une blocking queue, comme les mailbox d'Erlang ou les channels de Go bref le design pattern producteur/consommateur. J'ai justement une PR ouverte sur l'API de structured concurrency de Java pour ajouter une blocking queue cachée derrière un Stream [1].



Alexandre

Rémi


Reply all
Reply to author
Forward
0 new messages