Spring WebFlux is a reactive web framework that uses Reactive Streams and non-blocking behavior to provide better scalability than traditional Spring MVC. It uses a small number of threads to handle requests asynchronously through reactive programming. Spring WebFlux supports both annotation-based and functional programming models for building reactive server-side web applications that can handle HTTP requests and WebSockets in a non-blocking manner through reactive streams. Router functions route incoming requests to handler functions based on matching predicates.

1. Web on reactive stack
Spring WebFlux

2. Spring WebMVC
● Purpose-built for the Servlet API and Servlet containers
● Inherently blocking
● Imperative programming model
● Scales poorly.

3. Reactive Programming
● Based on events - reacting to changes : network components reacting to I/O
events, UI controllers reacting to mouse events
● non-blocking back pressure
● require a small number of threads to scale vertically
● Forgo raw performance in favor of scalability
data repository
(Publisher)
HTTP Server
(Subscriber)Response

4. Spring Web Flux
● Support for reactive HTTP and WebSocket clients
● Supports reactive server web applications including REST and WebSocket
style interactions
● Uses ReactiveStreams underneath
● Extends the basic Reactive Streams Publisher contract with the Flux and
Mono composable API types

5. Spring Web Flux - Server Side
supports 2 distinct programming models:
● Annotation-based with @Controller and the other annotations supported also
with Spring MVC
● Functional, Java 8 lambda style routing and handling

6. Router Functions
● Routes incoming requests to Handler Functions
● If a request matches a particular route, a handler function is returned;
otherwise it returns an empty Mono
● If the predicate applies, the request is routed to the given handler function;
otherwise no routing is performed, resulting in a 404 response
● Source code: https://github.com/ravindraranwala/reactive-webflux-demo

7. Concurrency Model
● Servlet Applications - Current thread can be blocked, so a large thread pool is
used to absorb potential blocking.
● non-blocking servers use a small, fixed-size thread pool to handle requests