Should I migrate to Reactive and how?
summary
Explains when to migrate to reactive: it’s beneficial for higher concurrency rather than lower latency, showing an example where an I/O-bound downstream service (300 ms) saturates an imperative server at ~300 threads while a reactive server handles many more with ~30 threads. Demonstrates the Spring Reactor stack—Mono/Flux, WebFlux, WebClient, and R2DBC for nonblocking DB access—while warning R2DBC lacks joins/pagination (so migrations may require schema changes or adapter layers), and covers runtime/testing considerations like using Reactor Context for MDC/security, detecting blocking calls with BlockHound, and using virtual time for deterministic tests.
AI-written summary · about
chapters (19)
- 0:00Reactive migration intro
- 1:03Imperative limits
- 3:32Reactive principles
- 5:21Reactive vs imperative perf
- 7:25Reactive Streams and Reactor API
- 10:15Java reactive impls
- 12:47Mono and Flux creation
- 15:56Reactive code example
- 18:28Threads and reactive context
- 20:32Reactive unit tests
- 22:41Reactive learning curve
- 23:23Migrating Spring MVC
- 26:57R2DBC data access
- 30:12R2DBC joins and limits
- 33:26Blocking detection tools
- 35:14Security and reactive context
- 36:38Monitoring with Actuator
- 38:05Should I migrate?
- 39:49Q&A
