0

When building a standard web Apis in Java world there is two ways I could do nowadays

  1. Use SpringMVC (Not Reactive)
  2. Use SpringWebFlux (Reactive)

There are few benefits of using Reactive that I can think of

  • It uses less memory resources as there is less thread running (maybe better for a container based deployment)
  • It is better for scenario where your api might need to call other apis and you do not want to think of the concurrency problem (this is can be done in traditional webmvc also but then you need to use completableFuture etc whereas in reactive you let the framework handle it)

There are few disadvantages I can think of when using Reactive

  • Code complexity, as now everything is chained and you need to take care of not blocking the thread and need to be aware of fact that there is no ThreadLocal as such things like logging using MDC is more complicated now
  • Increase in latency as there are fewer threads now

One of the selling point of reactive way of doing things is the backpressure concept but when comes to normal request/response in web apis there is no usage of it as either you process it or you do not there is no process up the chain that will reduce the production of data.

I am not sure if the benefit that I laid down above is worth the complexity for a web apis. I would like to hear thoughts on that. If web apis is not the right place to use reactive where would you think is the right place to use it. Or if reactive way is the way to do it then does not mean there is no place any more for traditional webmvc way of doing things?

  • The latency can be effectively mitigated by running multiple instances of the server in parallel behind a load balancer. – Alex Reinking Dec 17 '18 at 23:31
  • agree that can be done. So are you in the reactive camp for rest web apis ? – tabiul Dec 17 '18 at 23:54
  • 1
    I'm more broadly in the camp of asynchronous models for IO bound workloads. – Alex Reinking Dec 18 '18 at 0:01
  • From my understanding a reactive system is far more responsive to load (and can handle a greater load for a smaller footprint) – Jags Dec 18 '18 at 0:36
1

The biggest reason to use a reactive (read: asynchronous) architecture for a web server is that they're much more efficient in terms of throughput and consequently can scale vertically much better than classic servlet / one-thread-per-connection models. This efficiency translates to greater robustness under load, better connection speeds and latencies (when scaling horizontally), and ultimately a better user experience.

In response to your other question:

Or if reactive way is the way to do it then does not mean there is no place any more for traditional webmvc way of doing things?

There is a place for this: when scalability is not a factor or when added the added complexity (though "unfamiliarity" might be more accurate) would add too greatly to the maintenance costs of the overall software. For instance, Python's built-in web server, or CUPS's web-based printer management interface are good examples of when a very simple web server is perfectly appropriate for the usage.

However, a web API needs to handle thousands of concurrent connections almost by definition. So I would consider using a reactive framework (like Spring WebFlux) an absolute requirement if you're starting from scratch. The benefits certainly outweigh the training costs.

  • 1
    greater robustness under load, better connection speeds and latencies (when scaling horizontally), and ultimately a better user experience, I am not sure if there is any apis that do not want that :) so in that sense other then very simple cases reactive is the way to go – tabiul Dec 18 '18 at 1:05
  • @tabiul - yeah, that is the argument I'm putting forth. Although the traditional model might still be perfectly suitable for complex in-house web interfaces to software if it has to deal with only hundreds, not thousands of concurrent connections. – Alex Reinking Dec 18 '18 at 1:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.