• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Rob Spoor
  • Tim Cooke
  • Junilu Lacar
Sheriffs:
  • Henry Wong
  • Liutauras Vilda
  • Jeanne Boyarsky
Saloon Keepers:
  • Jesse Silverman
  • Tim Holloway
  • Stephan van Hulst
  • Tim Moores
  • Carey Brown
Bartenders:
  • Al Hobbs
  • Mikalai Zaikin
  • Piet Souris

Spring in Action: Reactor

 
Greenhorn
Posts: 29
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Good day,

Reactive applications are the "hot new thing", but what should be the criterias/factors a development team should consider using it instead of a traditional blocking application?

Regards,
Joey
 
author
Posts: 422
13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Jose Samonte wrote:Good day,

Reactive applications are the "hot new thing", but what should be the criterias/factors a development team should consider using it instead of a traditional blocking application?

Regards,
Joey



That's a tough one to answer, because it's hard to give a blanket statement for all projects, when individual project goals will vary. But...to put it in a general statement...

Reactive, in a nutshell, enables an application to do more with less: Achieve more with fewer threads, rather than a large thread pool. The key difference is that those few threads are super-busy, rather than lots of threads in a pool that are being swapped out (and paying the overhead for that swapping).

So even if a project doesn't really need the benefits of reactive, then there can be some benefits realized. The gotchas, however, might guide you toward avoiding reactive. Specifically...

- A little reactive sprinkled into an otherwise imperative/blocking application won't see too many benefits and possibly might make things worse. You won't realize the full benefits of reactive unless the project is fully reactive.
- There are situations where reactive isn't an option. JDBC/JPA-centric persistence will be block and affect the benefits of reactive upstream. R2DBC and Spring Data R2DBC offer some reactive benefits for certain relational databases, but  if that's not your database, then you're out of luck. Mongo, Cassandra, and a few others are great options for non-blocking persistence, but those may or may not be options for you.
- Reactive thinking twists the brain differently than imperative programming. In other words, there's a learning curve and your team will all need to be reactive-minded or else you'll find someone writing some really bad "reactive" code that actually creates blocks. Fortunately, Spring (as much as possible) makes the transition to reactive easy; specifically, I'm thinking of Spring WebFlux vs. Spring MVC where the programming model is nearly identical. But you'll still need to understand how to write reactive code within your controller methods and the backend components that your controller consumes.

But again, there's no general advice I can give. I tend to favor the benefits of reactive, but honestly...I sometimes start off with non-reactive just to get started and then transition as the project matures. (Of course, if you wait too long to make that transition, then you'll have quite a chore on your hands.)
 
reply
    Bookmark Topic Watch Topic
  • New Topic