What this prompt does
This prompt builds a reactive application with Spring WebFlux for [use_case]. It covers functional routing with RouterFunction/HandlerFunction, reactive database access via [reactive_db_driver], a Server-Sent Events endpoint streaming [sse_data], non-blocking WebClient calls to [external_apis] with retry and circuit breaker, reactive security, backpressure handling, reactive error handling, reactive caching with [cache_strategy], testing with StepVerifier and WebTestClient, and a performance comparison against traditional MVC — including an explicit "when NOT to use WebFlux" section.
The structure works because WebFlux is often adopted as a default when it should not be. The honest "when NOT to use it" section — blocking libraries, simple CRUD — is the most valuable part, because a single blocking call in a reactive chain quietly stalls the event loop. By naming [reactive_db_driver] (a fully reactive driver, not a blocking JDBC one) and demanding backpressure strategies, the prompt steers toward genuinely non-blocking code rather than reactive-looking code that blocks underneath.
When to use it
- When a
[use_case]truly needs streaming or very high concurrency - When pushing live updates to clients via Server-Sent Events (
[sse_data]) - When aggregating from several
[external_apis]with different rate limits non-blockingly - When you need backpressure handling for high-throughput data flows
- When you want an honest comparison of WebFlux versus MVC before committing
- When the whole stack, including the database driver, can be made non-blocking
Example output
You get a complete WebFlux example: functional routes using RouterFunction and HandlerFunction, reactive data access with [reactive_db_driver], the SSE endpoint streaming [sse_data] to connected clients, resilient WebClient calls to [external_apis] with retry and circuit breaker, reactive security via SecurityWebFilterChain, backpressure strategies for high-throughput flows, error handling with onErrorResume, onErrorReturn, and a global WebExceptionHandler, [cache_strategy] caching with a reactive adapter, StepVerifier and WebTestClient tests, a docker-compose, and a performance comparison against MVC. Crucially it ends with a clear, honest note on when not to use WebFlux for [use_case], namely blocking libraries and simple CRUD.
Pro tips
- Use a truly reactive
[reactive_db_driver]like R2DBC; a blocking JDBC call inside a reactive chain stalls the event loop and erases WebFlux's benefits - Take the "when NOT to use it" section seriously — for simple CRUD, traditional MVC is easier to write, read, and debug
- Add retry and circuit breaker to every WebClient call to
[external_apis], since one slow upstream can otherwise back up the whole pipeline - Choose a concrete backpressure strategy for high-throughput flows rather than relying on defaults that may drop or buffer unexpectedly
- Verify the
[cache_strategy]adapter is reactive too; a blocking cache lookup defeats the non-blocking model - Lean on StepVerifier in tests to assert the exact emission and completion behavior of your reactive streams
