Spring WebFlux is a reactive programming framework introduced in Spring 5 to handle asynchronous, non-blocking web applications. It is designed to provide a scalable and efficient solution for handling concurrent requests, making it ideal for modern cloud-native applications, microservices, and streaming data scenarios.

Why Spring WebFlux?

Traditional Spring MVC applications use a synchronous, thread-per-request model, which can be inefficient when dealing with high concurrency and slow I/O operations. WebFlux, on the other hand, is built on Project Reactor, leveraging reactive programming principles to enable non-blocking execution, thus improving resource utilization and scalability.

Key reasons to use Spring WebFlux:

• Non-blocking I/O: It handles multiple requests efficiently without blocking threads.
• Better scalability: Optimized for high-throughput applications.
• Backpressure handling: Supports Reactive Streams specification to manage data flow effectively.
• Microservices-friendly: Well-suited for cloud-native and distributed architectures.
• Streaming support: It handles large streams of data efficiently.

Core Concepts of Spring WebFlux

Spring WebFlux is built around reactive programming principles. Here are its core components:

1. Reactive Streams & Project Reactor

Spring WebFlux is based on the Reactive Streams specification and implements it using Project Reactor, which introduces two key types:

• Mono – Represents a single asynchronous value.
• Flux – Represents a stream of multiple asynchronous values.

Example:

Mono<String> mono = Mono.just("Hello, WebFlux!");
Flux<Integer> flux = Flux.range(1, 5);Code language: HTML, XML (xml)

2. Annotated Controllers (Spring MVC Style)

WebFlux supports annotated controllers similar to Spring MVC, using @RestController and @RequestMapping.

Example:

@RestController
@RequestMapping("/users")
public class UserController {
    @GetMapping("/{id}")
    public Mono<User> getUserById(@PathVariable String id) {
        return userService.findById(id);
    }
}Code language: CSS (css)

3. Functional Endpoints (Alternative to Controllers)

WebFlux also provides a functional programming style using RouterFunction and HandlerFunction.

Example:

@Bean
public RouterFunction<ServerResponse> routes(UserHandler userHandler) {
    return RouterFunctions.route()
        .GET("/users/{id}", userHandler::getUserById)
        .build();
}Code language: PHP (php)

4. WebClient (Alternative to RestTemplate)

Spring WebFlux introduces WebClient, a non-blocking alternative to RestTemplate for making HTTP calls.

Example:

WebClient webClient = WebClient.create("https://api.example.com");
Mono<User> userMono = webClient.get()
    .uri("/users/1")
    .retrieve()
    .bodyToMono(User.class);Code language: PHP (php)

Threading Model in Spring WebFlux

Spring WebFlux follows an event-driven, non-blocking threading model, making it significantly different from the traditional Spring MVC model.

Netty vs. Servlet Containers:

• WebFlux can run on Netty, a lightweight, non-blocking web server, or on traditional servlet containers like Tomcat, Jetty, or Undertow in reactive mode.
• When running on Netty, WebFlux operates with a small, fixed number of event loop threads, optimizing performance.

Thread Management in WebFlux:

• The default thread pool for handling requests is called the Reactor Netty Event Loop.
• A separate thread pool (boundedElastic) is used for blocking tasks (e.g., database interactions if a reactive driver is unavailable).
• Parallel Schedulers can be used for CPU-intensive tasks.

Threading in Request Handling:

• WebFlux does not create a new thread per request (as in Spring MVC). Instead, it uses asynchronous, event-driven processing.
• A single thread can handle multiple requests concurrently through callbacks and event loops.
• Developers must be cautious when mixing blocking operations with WebFlux, as it can degrade performance.

Best Practices for Thread Management:

• Traditional JDBC calls (e.g., using JPA/Hibernate)
• File I/O operations
• External API calls using RestTemplate

Handling Blocking Calls in Spring WebFlux

Spring WebFlux is designed for non-blocking execution, but sometimes blocking operations (e.g., JDBC calls, legacy APIs) need to be handled carefully to avoid performance issues.

1. Identifying Blocking Code

Blocking operations include:

2. Using Schedulers.boundedElastic() for Blocking Tasks

WebFlux provides Schedulers.boundedElastic() for executing blocking operations on a separate thread pool.

Example:

Mono<User> userMono = Mono.fromCallable(() -> userRepository.findById(1))
    .subscribeOn(Schedulers.boundedElastic());Code language: HTML, XML (xml)

This shifts the blocking call to a dedicated thread pool, preventing it from interfering with the event loop threads.

3. Using parallel() for CPU-Intensive Tasks

For CPU-bound operations, use parallel() to optimize execution.

Example:

Flux.range(1, 10)
    .parallel()
    .runOn(Schedulers.parallel())
    .map(i -> compute(i))
    .sequential()
    .subscribe();Code language: CSS (css)

4. Handling External API Calls Efficiently

Instead of RestTemplate, use WebClient to perform non-blocking HTTP requests.

Example:

Mono<Response> response = webClient.get()
    .uri("/external-service")
    .retrieve()
    .bodyToMono(Response.class);Code language: PHP (php)

5. Best Practices for Handling Blocking Code

• Minimize blocking calls by using reactive alternatives wherever possible.
• Isolate blocking operations boundedElastic() to avoid blocking event loop threads.
• Monitor and detect blocking calls using tools like BlockHound.

Best Practices for Using Spring WebFlux

To maximize the benefits of Spring WebFlux, follow these best practices:

1. Use Reactive Data Stores: Choose non-blocking databases such as R2DBC, MongoDB (Reactive Driver), or Cassandra to maintain a fully reactive stack.
2. Avoid Blocking Calls: Do not mix blocking operations (e.g., JDBC, JPA) with WebFlux, as it can degrade performance and reduce scalability.
3. Handle Backpressure Properly: Use Reactive Streams‘ backpressure mechanisms to avoid overwhelming consumers with too much data.
4. Leverage WebClient Over RestTemplate: Prefer WebClient for making HTTP requests, as it is fully non-blocking and supports reactive data processing.
5. Optimize Thread Utilization: Use Schedulers effectively to control execution threads and avoid unnecessary context switching.

Conclusion

Spring WebFlux provides a powerful, reactive approach to web development, enabling non-blocking, high-performance applications. By understanding its threading model, avoiding blocking calls, and following best practices, developers can fully harness the power of WebFlux to build highly scalable and resilient applications.

References

Spring Webflux – Spring.io