Spring WebFlux 2: Alta Concurrencia sin Más Hilos

¡Bienvenido de nuevo a nuestra inmersión en Spring WebFlux! 👋

En la primera parte de esta serie, exploramos el “por qué” de la programación reactiva, entendiendo los problemas del bloqueo y descubriendo a Project Reactor como el motor que impulsa los flujos de datos asíncronos. Ahora que tenemos una base sólida sobre los principios reactivos y los tipos Mono/Flux, es momento de subir un nivel y entender cómo Spring WebFlux aplica estos conceptos para construir aplicaciones web eficientes y escalables.

En esta segunda entrega, nos centraremos en la arquitectura que diferencia a WebFlux de su predecesor, Spring MVC, y aprenderemos las dos formas principales de definir los endpoints de nuestra API reactiva.

3. Arquitectura de Spring WebFlux

Si Spring MVC se construyó sobre la API de Servlets (diseñada originalmente para un modelo síncrono de un hilo por petición), Spring WebFlux se construye sobre una pila completamente reactiva y no bloqueante. Esta diferencia fundamental es la clave de su capacidad para manejar alta concurrencia.

Teoría: Componentes Clave

La arquitectura de WebFlux se basa en:

• Servidores No Bloqueantes: A diferencia de depender de un Contenedor de Servlets (como Tomcat, Jetty) configurado de forma tradicional, WebFlux utiliza servidores web diseñados para manejar I/O no bloqueante. El servidor por defecto integrado con Spring Boot WebFlux es Netty, un framework asíncrono basado en eventos muy popular en la industria por su rendimiento. Sin embargo, WebFlux es flexible y también soporta otros servidores reactivos como Undertow o incluso Servlets 3.1+ API en modo no bloqueante (aunque el uso de Netty o Undertow es más común y eficiente para aprovechar plenamente el potencial reactivo).
• EventLoop: El corazón del procesamiento no bloqueante. En lugar de asignar un hilo por petición, WebFlux (y los servidores como Netty) utilizan un pequeño número de hilos llamados “Event Loop threads”. Estos hilos no realizan operaciones de I/O bloqueantes directamente. En cambio, delegan la operación al sistema operativo y quedan libres para procesar otras tareas o peticiones. Cuando la operación de I/O se completa (por ejemplo, llega la respuesta de una base de datos o un servicio externo), el sistema operativo notifica al Event Loop, que entonces toma el resultado y continúa el procesamiento del flujo reactivo asociado a esa petición.
• Reactor Core: Como vimos en la Parte 1, Project Reactor proporciona los tipos Mono y Flux y los operadores para componer la lógica asíncrona. WebFlux se integra estrechamente con Reactor.
• Spring Web Reactive Framework: Capas por encima de Reactor y el servidor para proporcionar la funcionalidad web: manejo de peticiones, ruteo, serialización/deserialización, manejo de errores, etc.

Cómo WebFlux Maneja las Peticiones (El Pipeline Reactivo)

Cuando una petición HTTP llega a un servidor WebFlux:

1. Uno de los Event Loop threads del servidor la recibe.
2. La petición pasa a través de la cadena de procesamiento de WebFlux (filtros, ruteo).
3. La petición llega al Handler (controlador o función manejadora) correspondiente.
4. El Handler ejecuta la lógica de negocio, que típicamente involucra operaciones que devuelven Mono o Flux (ej: llamar a un servicio, acceder a una base de datos reactiva).
5. Estas operaciones, al ser reactivas y no bloqueantes, no detienen el Event Loop thread. El thread delega la tarea (ej: consulta a DB) y queda libre.
6. Cuando la operación asíncrona finaliza (ej: la DB devuelve resultados), uno de los Event Loop threads recibe la notificación.
7. Los resultados fluyen de vuelta a través de la cadena de operadores definida en el Mono/Flux.
8. El resultado final del Mono/Flux se convierte en una respuesta HTTP y se envía de vuelta al cliente, de nuevo, utilizando los Event Loop threads de forma no bloqueante.

Todo el procesamiento, desde la recepción de la petición hasta el envío de la respuesta, se maneja sin bloquear los hilos principales, permitiendo que un pequeño número de hilos gestione una alta concurrencia.

Diferencias Arquitectónicas Fundamentales con Spring MVC

Característica	Spring MVC (Tradicional)	Spring WebFlux (Reactivo)
Modelo de Hilos	Thread-per-request (Bloqueante)	Event Loop (No Bloqueante)
Contenedor/Servidor	Basado en Servlet API (Tomcat, Jetty, etc.)	Basado en servidores reactivos (Netty, Undertow) o Servlet 3.1+ no bloqueante
Manejo de I/O	Bloqueante (por defecto)	No Bloqueante
Dependencies Base	spring-webmvc	spring-webflux
Tipos de Retorno	Objetos POJO, ResponseEntity, ModelAndView, etc.	Mono<?>, Flux<?>, ResponseEntity<Mono<?>>, etc.
Backpressure	No aplica directamente	Soportado nativamente a través de Reactive Streams

¿Puedes usar Spring MVC y Spring WebFlux en el mismo proyecto?

Generalmente no. Aunque es técnicamente posible tener ambas dependencias en el classpath, Spring Boot configurará automáticamente solo una de las dos pilas web (MVC o WebFlux) basándose en la que encuentre primero o una configuración explícita. Son dos arquitecturas de manejo de peticiones fundamentalmente diferentes que no están diseñadas para coexistir y procesar la misma petición dentro del mismo contexto de aplicación Spring de forma híbrida y coherente. Debes elegir una u otra para tu aplicación web principal.

Casos Típicos/Práctica

• Flujo de una Petición Típica en WebFlux:

  1. Llega petición HTTP a Netty (Event Loop thread A la recibe).
  2. WebFlux la rutea a un HandlerFunction (el mismo thread A).
  3. El Handler llama a un UserService.findById(id) que devuelve Mono<User>.
  4. UserService usa un ReactiveUserRepository.findById(id) (que usa un driver R2DBC no bloqueante).
  5. El Event Loop thread A delega la consulta a la DB y queda libre.
  6. Cuando la DB responde, otro Event Loop thread (B) recibe la notificación.
  7. El thread B retoma el flujo del Mono<User>.
  8. El resultado User fluye de regreso al Handler.
  9. El Handler devuelve el Mono<User>, que WebFlux serializa a JSON.
  10. El Event Loop thread B envía la respuesta HTTP de vuelta al cliente.

• Modelo de Hilos de Spring MVC vs. WebFlux:

  • MVC: Un pico de 1000 peticiones concurrentes esperando por una DB lenta podría requerir 1000 hilos (o el tamaño máximo del pool), muchos de ellos inactivos.
  • WebFlux: Esas mismas 1000 peticiones podrían ser manejadas por 4-8 Event Loop threads, que nunca esperan, simplemente gestionan el estado de las operaciones asíncronas pendientes. Esto libera recursos para otras tareas.

4. Creación de Endpoints (Controladores y Endpoints Funcionales)

Spring WebFlux ofrece dos enfoques principales para definir los puntos finales de tu API: el modelo tradicional basado en anotaciones y un modelo más funcional.

Teoría: Dos Enfoques

1. Basado en Anotaciones: Similar a Spring MVC, usas anotaciones como @RestController, @RequestMapping, @GetMapping, @PostMapping, @RequestBody, etc. La diferencia clave es que los métodos del controlador deben devolver tipos reactivos (Mono<?> o Flux<?>).
2. Endpoints Funcionales: Un enfoque más funcional y declarativo. Defines las rutas usando RouterFunction y los manejadores de peticiones usando HandlerFunction. No hay anotaciones a nivel de método o clase; es todo código Java.

Uso de Anotaciones con Tipos Reactivos

Es el enfoque más familiar si vienes de Spring MVC. Simplemente creas clases con @RestController y métodos con anotaciones de mapeo HTTP. La diferencia crucial es el tipo de retorno:

• Devuelve Mono<T> si esperas 0 o 1 objeto T en la respuesta.
• Devuelve Flux<T> si esperas 0 a N objetos T en la respuesta (esto puede ser un array JSON o un stream de datos, por ejemplo, en Server-Sent Events).
• Puedes envolver el tipo reactivo en ResponseEntity para tener control sobre el estado HTTP, cabeceras, etc.: Mono<ResponseEntity<T>> o ResponseEntity<Flux<T>>.

Recibir datos en el cuerpo de la petición también se hace reactivamente: usas @RequestBody con Mono<T>.

Uso de Endpoints Funcionales

Este enfoque desacopla completamente la definición de la ruta de la lógica de manejo de la petición.

• RouterFunction<ServerResponse>: Define cómo las peticiones se rutean a los HandlerFunction basándose en predicados (métodos HTTP, rutas, cabeceras, etc.). Usas la clase RouterFunctions para construirlas (route(RequestPredicate, HandlerFunction)).
• HandlerFunction<ServerResponse>: Contiene la lógica de negocio para manejar una petición. Recibe un ServerRequest como entrada y devuelve un Mono<ServerResponse>. La clase ServerResponse se usa para construir la respuesta (estado HTTP, cuerpo, cabeceras).

Ventajas del Enfoque Funcional:

• Mayor separación de preocupaciones (ruteo vs. manejo).
• Más fácil de testear unitariamente (HandlerFunction es solo una función pura).
• Permite una construcción de rutas más programática y dinámica.
• Evita el uso de reflexion asociado a las anotaciones (micro-optimización).

Desventajas del Enfoque Funcional:

• Puede ser menos conciso y legible para APIs REST simples comparado con las anotaciones.
• Menos familiar para desarrolladores acostumbrados al modelo de anotaciones.

Casos Típicos/Práctica

• Endpoint GET que devuelva un Mono<MyObject> (Anotaciones):

  Asumiendo una clase MyObject { String message; }

  @RestController
  @RequestMapping("/api/greeting")
  public class GreetingController {
  
      @GetMapping("/{name}")
      public Mono<MyObject> getGreeting(@PathVariable String name) {
          // Simula una operación asíncrona que devuelve un solo objeto
          return Mono.just(new MyObject("Hello, " + name))
                     .delayElement(Duration.ofMillis(500)); // Simula latencia
      }
  }

• Endpoint GET que devuelva un Flux<MyObject> (Stream de datos) (Anotaciones):

  @RestController
  @RequestMapping("/api/numbers")
  public class NumberStreamController {
  
      @GetMapping(value = "/stream", produces = MediaType.TEXT_EVENT_STREAM_VALUE) // Importante: MediaType.TEXT_EVENT_STREAM_VALUE para SSE
      public Flux<String> streamNumbers() {
          // Emite un número cada segundo indefinidamente
          return Flux.interval(Duration.ofSeconds(1))
                     .map(sequence -> "Event: " + sequence);
      }
  
      @GetMapping("/list") // Devuelve como JSON array
      public Flux<MyObject> getObjectsList() {
          return Flux.just(new MyObject("one"), new MyObject("two"), new MyObject("three"))
                     .delayElements(Duration.ofMillis(100));
      }
  }

• Endpoint POST que reciba un Mono<MyObject> en el body (Anotaciones):

  @RestController
  @RequestMapping("/api/objects")
  public class ObjectController {
  
      @PostMapping
      public Mono<String> createObject(@RequestBody Mono<MyObject> objectMono) {
          // Recibe un Mono<MyObject> del cuerpo de la petición
          // flatMap es necesario porque objectMono es un Publisher y save es otro Publisher
          return objectMono
                  .flatMap(obj -> {
                      System.out.println("Recibido objeto: " + obj.getMessage());
                      // Simula guardar el objeto asíncronamente y devolver un ID
                      return Mono.just("Object saved with ID: " + obj.getMessage().hashCode())
                                 .delayElement(Duration.ofMillis(300));
                  });
      }
  }

• Definir una ruta y su manejador usando el enfoque funcional:

  Primero, el HandlerFunction:

  // En un archivo separado, por ejemplo, src/main/java/com/example/demo/handler/GreetingHandler.java
  @Component // Spring lo detecta como un Bean
  public class GreetingHandler {
  
      public Mono<ServerResponse> getGreeting(ServerRequest request) {
          String name = request.pathVariable("name");
          return Mono.just(new MyObject("Hello, " + name))
                     .delayElement(Duration.ofMillis(500)) // Simula latencia
                     .flatMap(obj -> ServerResponse.ok() // Construye la respuesta HTTP 200
                                                   .contentType(MediaType.APPLICATION_JSON) // Define el tipo de contenido
                                                   .bodyValue(obj)); // Pone el objeto en el cuerpo de la respuesta
      }
  
       public Mono<ServerResponse> createObject(ServerRequest request) {
           return request.bodyToMono(MyObject.class) // Extrae el cuerpo a un Mono<MyObject>
                  .flatMap(obj -> {
                      System.out.println("Recibido objeto (Funcional): " + obj.getMessage());
                       // Simula guardar
                      return Mono.just("Object saved (Funcional) with ID: " + obj.getMessage().hashCode())
                                 .delayElement(Duration.ofMillis(300));
                  })
                  .flatMap(responseString -> ServerResponse.status(HttpStatus.CREATED) // Construye respuesta 201 Created
                                                            .contentType(MediaType.TEXT_PLAIN)
                                                            .bodyValue(responseString));
       }
  }

  Luego, el RouterFunction (en una clase de configuración, por ejemplo):

  // En una clase de configuración, por ejemplo, src/main/java/com/example/demo/config/RoutingConfig.java
  @Configuration
  public class RoutingConfig {
  
      @Bean
      public RouterFunction<ServerResponse> route(GreetingHandler greetingHandler) {
          return RouterFunctions.route(GET("/api/functional/greeting/{name}").and(accept(MediaType.APPLICATION_JSON)), greetingHandler::getGreeting)
                 .andRoute(POST("/api/functional/objects").and(contentType(MediaType.APPLICATION_JSON)), greetingHandler::createObject); // Combina con otras rutas
      }
  }

• ¿Cuándo elegirías anotaciones vs. endpoints funcionales?

  • Anotaciones: Ideal para proyectos que migran de Spring MVC, equipos familiarizados con el modelo de anotaciones, o APIs REST con estructuras estándar. Es a menudo más rápido de implementar para casos simples o CRUDs.
  • Funcionales: Preferible para APIs con lógica de ruteo compleja o dinámica, si buscas una mayor separación de preocupaciones para facilitar el testing unitario de la lógica del manejador, o si simplemente prefieres un estilo más funcional y programático. Puede tener una curva de aprendizaje inicial si no estás acostumbrado.

Conclusión

En esta segunda entrega, hemos explorado la arquitectura fundamental de Spring WebFlux, entendiendo cómo su modelo no bloqueante basado en EventLoop y servidores como Netty le permite manejar eficientemente la alta concurrencia, a diferencia del modelo tradicional de Spring MVC. También hemos aprendido las dos vías principales para construir endpoints: el familiar enfoque basado en anotaciones (adaptado para devolver tipos reactivos) y el modelo más programático y funcional de RouterFunction y HandlerFunction, comprendiendo las fortalezas de cada uno y cuándo considerar usarlos.

Con la arquitectura y la creación de endpoints cubiertas, estamos listos para abordar la interacción de nuestra aplicación WebFlux con el mundo exterior y el manejo de datos y errores. En la próxima parte, nos sumergiremos en el uso de WebClient para consumir servicios externos reactivamente, la integración con bases de datos reactivas (R2DBC, drivers NoSQL) y las estrategias para gestionar errores en los flujos reactivos.

¡Hasta la próxima entrega de nuestra serie sobre WebFlux!