使用 Mono 和 vanilla Java 编程的反应式编程之间的区别？

Question

I tried creating two api endpoints, one which is reactive and another is normal function(don't know what we call it, do let me know if you know:p) So according to theory, if I hit the Reactive end point two-three times at the same time which returns Mono<String> with time variable say 10000ms , then the app behave as it should, it doesn't block and run on separate threads which is expected. But with the normal function also, the behaviour is same, why so? Shouldn't it block the thread and block the other api call until the first one returns?

I was trying to see how does Mono&Flux practically achieve asynchronous behaviour? How does it really make a difference?

 @GetMapping(path = "/testing")
  public String testing(@RequestParam(value = "time") Long time) throws InterruptedException {
    log.info("Thread {}", Thread.currentThread().getName());
    Thread.sleep(time);
    return "RETURNING" + String.valueOf(time);
  }

  @GetMapping(path = "/testingFlux")
  public Mono<String> testinging(@RequestParam(value = "time") Long time) throws InterruptedException {
    log.info("Thread {}", Thread.currentThread().getName());
    Thread.sleep(time);
    return Mono.just("RETURNING" + String.valueOf(time));
  }

Answer 1

What you observe is Spring handling multiple Threads anyways in order to respond quickly and asynchronously/parallel to incoming requests.

There are are always multiple Worker-Threads handling requests at the same time. However "the difference" between the traditional and the reactive approach become greater under the hood.

You usually design an application to be reactive from ground to top, meaning it starts with a reactive data persistence over reactive domain model, reactive logic code and of course an api designed to work with reactive code.

Eventually it all boils down to: »You did not look deep enough into the rabbit hole, to see "the difference".« In fact there are plenty of concepts, which are a "must have" for reactive applications like often mentioned being "message driven", "resilient", "elastic". However you must take a deeper dive into programming a reactive application, to discover them.