• Impératif / Réactif
• Qu'est ce que Webflux ?
• Flux / mono
• Backpressure
• Opérateurs
• Modèle event loop
• Pools de threads
• Use cases

Sommaire

Mono : 0..1 éléments 

Ex: récupérer un objet "Véhicule" depuis un appel réseau Mono<Vehicule>.

On peut aussi faire Mono<List<Vehicule>> si l'API REST nous le permet

Flux: 0..N éléments

Ex: Faire de l'event sourcing pour l'exposer en REST

Ex: Interconnexion avec une fil de messages (Kafka,...)

Mono / flux

Est un système qui permet de réguler la transmission des éléments.


Car une approche non bloquante peut démultiplier des appels et provoquer des erreurs en cascade.

Concrètement cela permet :

• prévenir les défaillances systémiques

• contrôler le volume des éléments (delay, request, ....)

• gérer un tampon (buffer, ...)

• perdre les éléments en "trop" (cancel, ...)

Backpressure

- map, flatMap, filter, doOnNext
- Mono zip, zipWith
- Mono switchIfEmpty
- Mono onErrorResume
- Flux collectList

Opérateurs usuels

Modèle Event loop

Pools de thread

Webflux permet une gestion du threading via les classes "Scheduler" et "Worker".
- `Schedulers.immediate()` : évite de changer de thread (exécute maintenant^^)
- `Schedulers.single()` : réutilise un seul thread (pour les traitements à faibles latences)
- `Schedulers.parallel()` : définit N Worker (fonction des coeurs, pour les traitements rapides et non bloquants)
- `Schedulers.elastic() / Schedulers.boundedElastic()` : génère des threads à la demande (long traitement bloquant)
 

resilience4j

WebClient