In the world of Java web applications, Spring Framework stands out as a robust solution for building scalable and high-performance applications. With the introduction of Spring 5, Spring WebFlux was introduced as a reactive programming alternative to the traditional Spring MVC framework. Within this reactive landscape, two main architectural components are widely used to construct web layers: @Controller and RouterFunction . This article explores the differences between these two approaches, delving into their architectural styles, technical implementations, and practical use cases.

Architectural Styles

@Controller

The @Controller annotation is a staple of the Spring Framework, representing a stereotype for presentation-layer beans. When used with Spring WebFlux, the @Controller works similarly to Spring MVC but leverages reactive types.

• Declarative Routing: @Controller allows you to define request mappings using annotations such as @RequestMapping , @GetMapping , @PostMapping , etc. This declarative approach clearly associates HTTP endpoints with specific methods.
• Traditional MVC Style: It retains the traditional MVC pattern with model-view-controller triads.
• Usage of Handler Method Arguments: Handlers can use an extensive range of method arguments such as ServerHttpRequest , ServerHttpResponse , web session, etc.

Here's a simple example of a @Controller :

• Functional Routing: Instead of annotations, routes are defined using functional constructs provided by the RouterFunction builder.
• Predicate-based Request Mapping: Requests are mapped to handlers using predicates, offering flexibility and better control over the routing logic.
• Pipeline Composition: Handlers can be composed, allowing developers to build systems in a more declarative manner.
• Reactive Streams: Types such as Mono and Flux are central to Spring WebFlux, representing asynchronous single and multiple values, respectively.
• Non-blocking I/O: WebFlux operates on a reactive, non-blocking I/O architecture, allowing for higher scalability—each request operates as a non-blocking event-driven process.
• Backpressure: It manages data throughput, ensuring the system isn't overwhelmed by incoming data faster than it can process.
• Familiarity and Team Skillset: The choice between @Controller and RouterFunction may depend on the team's expertise. Teams more versed in traditional MVC may gravitate towards @Controller , while those familiar with the functional paradigm might prefer RouterFunction .
• Complexity and Application Needs: For complex applications that benefit from a functional approach and require intricate routing logic, RouterFunction might be favorable.
• Maintainability: For large-scale applications, the declarative style with @Controller may enhance readability and maintainability, particularly for teams working across multiple layers of an application.