Hi mboms! Nouvelle mode à l’horizon. Les développeurs front la suivent déjà depuis des lustres (notamment avec les library JS), mais les développeurs Java d’entreprise sont généralement à la traîne sur ce qui est trendy. Moi le premier.
Ce temps de latence a ses avantages et ses inconvénients. Personnellement, je m’efforce de m’intéresser à tout ce qui touche de près ou de loin mon écosystème technique. De cette manière, je peux ajouter chaque nouvelle techno / librairie à ma boîte à outils. Dès qu’on me formule un besoin, je plonge dans cette boîte et j’en sors celui qui est le plus adapté.
Il m’aura fallu près d’un an pour déterminer si je devais mettre la programmation réactive dans ma boîte à outils ou pas. Apprivoiser la bête n’est pas simple tellement elle change nos fondamentaux de la programmation Java. Le plus dur au final aura été de trouver une simple explication de pourquoi la programmation réactive sauvera tous nos vies.
Analysons brièvement la programmation réactive, en observant de plus près les bénéfices qu’elle apporte à la programmation non bloquante, et regardons quelques conseils pour l’implémenter.
De nos jours, nous sommes tous bombardés par la dernière tendance du moment: Programmation réactive. Juste pour mentionner quelques exemples, nous pouvons voir Java et Spring déplaçant leurs produits dans cette direction. Pour cette raison, nous devrions savoir en quoi elle peut être utile.
Bien que les approches de blocage et de non-blocage ne soient pas des concurrents, il y aura toujours une discussion sur le point suivant: laquelle offrira plus d’avantages durant la programmation?
Blocking ou non-blocking
Commençons par décrire et nous concentrer sur l’approche de blocage.
Comme cela a été pendant plusieurs années un moyen simple et permettant de comprendre ce qui se passe, lorsqu’un service reçoit une requête. Un thread du pool de threads est assigné à cette requête. Quand la logique métier est terminée, la sortie est renvoyée, et ce Thread devient disponible à nouveau pour une autre requête.
Cette approche permet d’accepter un certain nombre de requêtes, la limite étant le nombre de threads.
En passant à l’approche réactive, et en simplifiant à nouveau le processus, un thread sera responsable de dispatcher les tâches entre les threads disponibles restants (n-1). Cela signifie que toutes les demandes seront acceptées et traitées dès que la logique métier sera terminée.
Le rôle de la programmation réactive
De nos jours, nous travaillons avec des machines auto-scalables dans notre infrastructure. La combinaison de l’auto scalabilité et du non-blocage nous permet de faire face à des situations dans lesquelles nos machines fonctionnent déjà à leur maximum.
Lorsqu’une situation inattendue nous amène à un scénario où nous sommes soudainement confrontés à une quantité de trafic exagérée, l’auto scalabilité et le non-blocage permettent aux services de continuer à accepter des demandes alors que nos autres instances sont entrain de s’apprêter à commencer à recevoir du trafic. Bien sûr, le temps de réponse sera affecté, mais au moins elles seront acceptés et traités.
Mais gardez une chose à l’esprit, si vous choisissez une approche réactive, cela doit être de bout en bout. Si vous définissez un code bloquant dans votre service non bloquant, il ne sera plus non-bloquant.
Conclusion
Lorsque la communauté bouge, il est toujours important de le prendre en compte. Dans ce post, j’ai analysé la programmation réactive et comment elle pourrait m’aider à faire face à des événements inattendus, comme un scénario où nous recevons une quantité exagérée de trafic.