Servlet or Reactive Stacks: The Choice is Yours. Oh No... The Choice is Mine! - Rossen Stoyanchev
Why Stack Overflow recommends it
Stack Overflow users link it when explaining how Spring MVC's Servlet model differs from WebFlux's non-blocking reactive model, especially to people confused about what reactive buys them.
Recommended by 3 people across 4 different months, 2018 to 2020.
What it is
A SpringOne Platform 2017 conference talk by Spring Framework developer Rossen Stoyanchev comparing Servlet-based Spring MVC with the reactive Spring WebFlux stack. It contrasts their execution models across common web application scenarios and uses sample code to show reactive behavior such as back pressure on each stack.
What people said
Recommends Brian Clozel · 2018-01 · Stack Overflow · on “Spring Boot 2 reactive webflux”
sayHello and sayHelloReactively can be both considered as reactive - you're basically returning something from memory, no I/O is involved. The second one wraps the String value for no reason - both methods are equivalent. The core idea behind reactive is that for everything that involves I/O operations (reading and writing from the network, for example), your code should not sit doing nothing while waiting for the result (REST call, database query) to come back. You can think of it as callbacks, plus many additional features like backpressure. Because NoteDao exposes synchronous+blocking methods, you can't call one method and be notified as soon as the result comes. Wrapping a blocking call
Recommends Brian Clozel · 2018-08 · Stack Overflow · on “Spring Reactor WebClient how does it achieve non-blocking?”
There are several separate questions here. How I/O operations are managed? What's the threading model behind this runtime? How does the application deal with the request/response model behind HTTP? In the case of WebClient and project Reactor, the Netty event loop is used to queue/dispatch/process events. Each read/write operation is done is a non-blocking manner, meaning that no thread sits waiting for an I/O operation to complete. In this model, concurrency is not done through thread pools, but there's a small number of threads that process unit of work which should never block. From a pure HTTP standpoint (i.e. if you were capturing the HTTP packets on the network), you'd see no big diffe
Recommends Brian Clozel · 2018-08 · Stack Overflow · on “WebFlux: Only one item arriving at the backend”
At that point, I think you should read a bit about the reactive model, as it's really different and can be confusing at first. See the Reactor ref docs on that: [LINK] and an intro from a Servlet point of view: [this video]
Recommends Druckles · 2019-05 · Stack Overflow · on “How to take advantage of non-blocking requests in Spring Web MVC Controllers”
It turns out that although the Servlet 3.1 specs support non-blocking IO, Spring MVC does not. To take full advantage of the reactive API, you must use WebFlux. See here for more information: [this video] . This image demonstrates how Spring MVC (on the left) works compared to Webflux (on the right). [LINK] I performed some more tests using Gatling [LINK] and had similar results: both took approximately the same amount of time, async was slightly less reliable. However, I did notice one semi-reproducable difference: the async results were sometimes quicker to respond: Normal [LINK] 50th percentile: 33.6 s 95th percentile: 35.4 s Reactive [LINK] 50th percentile: 6.51 s 95th percentile: 49.5 s I'm
Recommends Jalil.Jarjanazy · 2020-03 · Stack Overflow · on “Spring Boot backend and Angular frontend application”
You would follow the MVC pattern for each Spring Boot application you want to deploy on the servers. I recommend this [LINK] tutorial. Your Angular application would send HTTP requests for the corresponding SpringBoot application's endpoint (app1/getUsers) for example. Check here [LINK] . You can use the classic Servlet architecture with the synchronous blocking module of thread per request. Or, you can use Spring's new Reactor stack for asynchronous handling of requests. Check here [this video] for comparison.