Le blocage est mauvais, car il bloque un thread en attente d'une réponse. C'est très mauvais dans un cadre réactif qui a peu de threads à sa disposition, et est conçu pour qu'aucun d'entre eux devraient être inutilement bloqués.
C'est exactement ce que les frameworks réactifs sont conçus pour éviter, donc dans ce cas, cela vous empêche simplement de le faire :
Votre nouveau code, en revanche, fonctionne de manière asynchrone. Le thread n'est pas bloqué, car rien ne se passe réellement jusqu'à ce que le référentiel renvoie une valeur (puis le lambda que vous avez passé à savedQuote.subscribe() est exécuté, en imprimant votre résultat sur la console.)
Cependant, le nouveau code n'est toujours pas optimal/normal du point de vue des flux réactifs, car vous faites toute votre logique dans votre méthode d'abonnement. La chose normale à faire est de nous une série d'appels flatMap/map pour transformer les éléments dans le flux, et utiliser doOnNext() pour les effets secondaires (comme l'impression d'une valeur) :
stockQuoteClient.getQuoteStream()
.log("quote-monitor-service")
.flatMap(quoteRepository::insert)
.doOnNext(result -> System.out.println("I saved a quote! Id :: " + result.getId())))
.subscribe();
Si vous travaillez sérieusement avec des flux de réacteurs / réactifs, cela vaut la peine de les lire en général. Ils sont très puissants pour le travail non bloquant, mais ils nécessitent une façon de penser (et de coder) différente de celle de Java plus "standard".
