products-service

Great observation — the usage of WebClient, Flux, and Mono in Spring WebFlux follows a combination of modern design patterns and reactive programming paradigms. Let’s break it down:


Design Patterns Behind WebClient, Flux, and Mono

1. Builder PatternWebClient

Instead of passing all values to a constructor or method, you build the request step by step:

WebClient.create()
         .get()
         .uri("/example")
         .header("Authorization", "Bearer token")
         .retrieve()
         .bodyToMono(String.class);

This is Builder Pattern:


2. Chain of Responsibility / Fluent Interface


3. Reactor PatternFlux and Mono


4. Publisher-Subscriber Pattern – Flux & Mono

Mono<String> result = webClient.get().uri("/data").retrieve().bodyToMono(String.class);
result.subscribe(System.out::println);

This is a Publisher-Subscriber or Observer pattern:


Why Not One Method With All Params?

Using method chaining instead of one giant method:


Summary Table

Component Pattern(s) Used Purpose
WebClient Builder, Fluent Interface Build HTTP requests fluently
Mono/Flux Reactor, Publisher-Subscriber Non-blocking async programming
WebClient call chain Chain of Responsibility, Builder Step-by-step configuration

Let me know if you’d like a visual UML or example transforming this into a custom builder class.