Introduction à Spring Reactor et Spring Webflux

Introduction

Ce chapitre présente brièvement les nouveautés réactives de Spring 5. Les applications réactives avec Spring sont traitées plus en détail dans l’ouvrage "Java Spring - Construisez vos applications réactives avec une architecture micro-services en environnement Java EE" aux Éditions ENI.

L’objectif de la programmation réactive est de simplifier l’écriture d’applications asynchrones qui, au lieu d’utiliser le mécanisme classique d’un volumineux pool de threads bloquants, utilise une boucle et un nombre minimum de threads grâce à un moteur basé sur un framework NIO comme Netty.

Nous plaçons dans une file d’attente des traitements rapides à effectuer, et ils se font au fil de l’eau. Il devient alors possible de modéliser ces traitements sous la forme de flux et de propagations de changements. Nous pouvons gérer des flux statiques avec des tableaux ou dynamiques avec des émetteurs et récepteurs d’événements comme dans le design pattern observateur.

Dans un contexte de serveur d’un cluster élastique, ce type de traitement "sériel" permet de savoir si la charge sur un serveur est en adéquation avec la puissance du cluster via la backpressure qui mesure le volume du flux acceptable en entrée...

Spring Reactor

WebFlux

Nous utiliserons généralement Reactor dans le cadre d’applications WebFlux.

En effet les API Reactive sur des flux d’événements statiques sont souvent remplaçables par les Streams traditionnels. WebFlux est l’équivalent réactif de Spring MVC et utilise le moteur Reactor en interne.

Concevoir de zéro une application WebFlux est complexe. Depuis peu, JHipster permet de générer des applications complètes l’utilisant, et son utilisation peut faire gagner beaucoup de temps.

Pour utiliser Spring WebFlux, il faut ajouter la dépendance Maven :

<dependency> 
   <groupId>org.springframework.boot</groupId> 
   <artifactId>spring-boot-starter-webflux</artifactId> 
   <version>2.6.7</version> 
</dependency> 

Un exemple complet généré avec JHipster est disponible dans les exemples téléchargeables de l’ouvrage. Les détails le concernant sont étudiés dans un chapitre dédié.

Les tests avec WebFlux

Spring a mis à disposition un certain nombre d’outils pour faciliter les tests.

public class UtilisateurService { 
 public Mono<Utilisateur> getUtilisateurById(Integer utilisateurId) { 
 return webClient 
   .get() 
   .uri("http://localhost:8080/utilisateur/{id}", utilisateurId) 
   .retrieve() 
   .bodyToMono(Utilisateur.class); 
 } 
} 

@ExtendWith(MockitoExtension.class) 
public class UtilisateurServiceTest { 
   
 @Test 
 void givenUtilisateurId_whenGetUtilisateurById_thenReturnUtilisateur() { 
 
 Integer utilisateurId = 100; 
 Utilisateur mockUtilisateur = new Utilisateur(1, "Toto", 51); 
 when(webClientMock.get()) 
   .thenReturn(requestHeadersUriSpecMock); 
 when(requestHeadersUriMock.uri("/utilisateur/{id}", utilisateurId)) 
   .thenReturn(requestHeadersSpecMock); 
 when(requestHeadersMock.retrieve()) 
   .thenReturn(responseSpecMock); 
 when(responseMock.bodyToMono(Utilisateur.class)) 
   .thenReturn(Mono.just(mockUtilisateur)); 
 
 Mono<Utilisateur> utilisateurMono = 
utilisateurService.getUtilisateurById(utilisateurId); 
 
 StepVerifier.create(utilisateurMono) 
   .expectNextMatches(utilisateur -> utilisateur.getNom() 
   .equals("Toto")) 
   .verifyComplete(); 
 } 
} 

Server Site Event avec Spring

Il faut souvent, dans nos applications, faire des rafraîchissements pour des appels asynchrones. Il existe pour cela plusieurs technologies. La plus simple est le pooling qui consiste à interroger régulièrement le serveur pour connaître l’état d’avancement d’un traitement. Une autre évolution est le long pooling qui consiste à garder ouvert la connexion HTTP mais ces deux techniques sont dispendieuses au niveau du réseau. Une évolution existe avec les webhooks et le Publish-Subscribe. Nous avons ensuite les websockets qui sont bidirectionnelles. Nous avons aussi le Server Site Event, ou SSE en abrégé, qui est une norme HTTP permettant à une application web de gérer un flux d’événements unidirectionnel et de recevoir des mises à jour chaque fois que le serveur émet des données. Cette solution est souvent la mieux adaptée dans un contexte web qui ne requiert pas l’aspect temps réel des websockets. Nous sommes alors en léger différé mais cela est parfois soutenable.

La version Spring 4.2 supportait déjà le SSE, mais, à partir de Spring 5, il existe un moyen plus idiomatique et pratique de le gérer via un flux et un élément ServerSiteEvent grâce aux API réactives de Spring WebFlux. On crée...