When building a standard web Apis in Java world there is two ways I could do nowadays
- Use SpringMVC (Not Reactive)
- 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
completableFutureetc 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
ThreadLocalas 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?