1
votes

Reading Spring in action 5th edition chapter 11, last paragraph in section 11.1.2

By accepting a Mono as input, the method is invoked immediately without waiting for the Taco to be resolved from the request body. And because the repository is also reactive, it’ll accept a Mono and immediately return a Flux, from which you call next() and return the resulting Mono … all before the request is even processed!

How the service will immediately return before the request is even processed? Isn't that counter-intuitive? I mean should the request be processed first before returning a response?

1

1 Answers

1
votes

The book has everything you need. It is a well-written book, just make sure to read carefully while actually (make sure to download the source code from Manning) running the code. It will help you understand better.

From the book (https://livebook.manning.com/book/spring-in-action-fifth-edition/chapter-11/v-7/6):

Event Loop

11.1 Working with Spring WebFlux

Typical Servlet-based web frameworks, such as Spring MVC, are blocking and multithreaded in nature, using a single thread per connection. As requests are handled, a worker thread is pulled from a thread pool to process the request. Meanwhile, the request thread is blocked until it is notified by the worker thread that it is finished.

Consequently, blocking web frameworks do not scale effectively under heavy request volume. Latency in slow worker threads makes things even worse, because it will take longer for the worker thread to be returned to the pool to be ready to handle another request.

In some use cases, this arrangement is perfectly acceptable. In fact, this is largely how most web applications have been developed for well over a decade. But times are changing and the clients of these web applications have grown from people occasionally viewing websites on the web browser to people frequently consuming content and using applications that consume APIs. And these days the so-called "Internet of Things" where humans aren’t even involved while cars, jet engines, and other non-traditional clients are constantly exchanging data with our APIs. With an increasing number of clients consuming our web applications, scalability is more important than ever.

Asynchronous web frameworks, in contrast, achieve higher scalability with fewer threads—generally one per CPU core. By applying a technique known as event looping (as illustrated in Figure 11.1), these frameworks are able to handle many requests per thread, making the per-connection cost much cheaper.

In an event loop, everything is handled as an event, including requests and callbacks from intensive operations (such as database and network operations). When a costly operation is needed, the event loop registers a callback for that operation to be performed in parallel while the event loop moves on to handle other events. When the operation is complete, the completion is treated as an event by the event loop the same as requests. As a result, asynchronous web frameworks are able to scale better under heavy request volume with fewer threads (and thus reduced overhead for thread management).

Read the rest of this section and it will clarify any other concern.

Also, check Reactor https://github.com/reactor/reactor-core

For a complete example if you are still having difficulties https://www.baeldung.com/spring-webflux