CODEWITHSUNDEEP
reactive-programmingspring-webfluxproject-reactorreactive-streams
Nishant Bharat
Nishant Bharat

Reputation: 29

Why don't we see Reactive programming in all the web applications?

Reactive programming is a very useful way to increase the capacity of webservices because of non-blocking thread. I recently came to know about this programming paradigm and I want to use it for most of the applications I build. Despite being so efficient, I still see new applications being built in a blocking way. What are the reasons that reactive programming is not used everywhere as it's a nice paradigm and very efficient in handling users at scale?

I don't know if this question is too generic or suited for the platform. I tried searching on the internet and could not find any staisfactory information. Therefore, I am asking it here hoping foor someone experienced to help me with it. I am trying to learn Project Reactor for Reactive Spring.

Upvotes: 0

Views: 2086

Answers (1)

K.Nicholas
K.Nicholas

Reputation: 11551

Reactive, e.g, WebFlux, is to solve a specific problem that most websites won't experience. Regular servlet or dispatcher-based frameworks put each request on its own thread, which is generally fine. Soon Java will come with lightweight threads which is claimed to perform better than reactive anyway. Reactive is also based on function programming paradigm, which is a complicated and difficult way to write applications.

Reactive is meant to handle multiple requests on a single thread by using callbacks from I/O operations. If done correctly websites can handle more requests for the same number of threads than non-reactive. This would reduce resource costs and perhaps allow a service to be more responsive since starting regular threads is expensive.

In my experience, in practice, Reactor is not generally done correctly, has far more bugs due to the complexity of function programming, and takes much longer to deliver the code.

In my opinion, it can still be useful framework for simple services that are primarily I/O bound and have very little if any business logic. That is until lightweight threads become standard in the JDK and then maybe you have chosen the wrong path.

Also in my opinion, developers find it fun and exciting due to the functional programming paradigm, as do I. It's not a bad thing to use but shy away from it for important business related code/services.

Upvotes: 4

Related Questions