Do’s and Don’ts: Avoiding First-Time Reactive Programmer Mines
Why Stack Overflow recommends it
Stack Overflow users link it when answering Spring WebFlux and Reactor questions about schedulers, blocking code and mixing reactive with imperative style.
Recommended by 1 people across 1 different months, 2020 to 2022.
What it is
A 58-minute SpringOne Platform 2019 conference talk by Sergei Egorov of Pivotal on common mistakes new reactive programmers make with Spring WebFlux and Project Reactor. It covers blocking code detection with BlockHound, schedulers, and Mono and Flux pitfalls through a try, fail and repeat walkthrough.
What people said
Recommends p.streef · 2021-01 · Stack Overflow · on “How can I switch to the default thread pool in Spring Webflux / Reactor?”
The short answer is: you don't. Longer anwser: you should not care about which thread something runs on. You can watch this talk, it is one of the points mentioned: [this video] IF you are going to run something on a dedicated scheduler (for instance to run some blocking tasks) you should probably choose to go back to parallel or boundedElastic, depending on if your next steps are cpu bound or not.
Cites Toerktumlare · 2020-07 · Stack Overflow · on “Reactive Spring Boot: return evaluates before map finshed”
It's hard to follow along in your code because you are mixing and matching reactive programming with imperativ programming in a non best practice way. You code doesn't compile and you have several strange things like medID never being used and variables never declared like body . So i have only taken your code "as is", i have not produced a fully working example only a guide. You should pick to either go the reactive route, or the imperative route. Some parts of my answer will be opinionated, if anyone later will complain, so thats the disclaimer. First off, you are on each request creating several WebClients this is in my opinion considered bad practice. Creating a WebClient is sort of an e
Cites Alex · 2022-07 · Stack Overflow · on “Spring WebFlux: Refactoring blocking API with Reactive API, or should I?”
There are multiple questions here. Will try to highlight main points 1. Does it make sense refactoring to Reactive API? From the first look your application is IO bound and typically reactive applications are much more efficient because all IO operations are async and non-blocking. Reactive application will not be faster but you will need less resources to The only caveat is that in order to get all benefits from the reactive API, your app should be reactive end-to-end (reactive drivers for DB, reactive WebClient, …). All reactive logic is executed on Schedulers.parallel() and you need small number of threads (by default, number of CPU cores) to execute non-blocking logic. It’s still possibl