Win a copy of React Cookbook: Recipes for Mastering the React Framework this week in the HTML Pages with CSS and JavaScript forum!
  • 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 ...
  • Campbell Ritchie
  • Ron McLeod
  • Paul Clapham
  • Rob Spoor
  • Liutauras Vilda
  • Jeanne Boyarsky
  • Junilu Lacar
  • Tim Cooke
Saloon Keepers:
  • Tim Holloway
  • Piet Souris
  • Stephan van Hulst
  • Tim Moores
  • Carey Brown
  • Frits Walraven
  • Himai Minh

Reactive Spring

Posts: 8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I am working as a software developer on an IoT project.
Currently we are using Sprint Boot with MongoDB for our app.
Since we have not yet launched this app, we do not know what would be the number of people using it.

Is it a good idea to move towards Reactive MongoDB and WebFlux ?
The app is currently a monolith but we are planning to move it to microservices architecture. Is it a good idea to move towards microservices and maybe Reactive Microservices ?

Thanks for your suggestions.

Posts: 2113
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You can break a monolith into microservices and use MongoDB. But there will be a lot of effort.
Posts: 22394
Eclipse IDE Spring VI Editor Chrome Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Splitting a monolith into microservices is going to take time. That's probably acceptable though, so let's ignore that.

Making applications reactive is probably worth the effort. The non-reactive applications are probably spending quite some time waiting on systems like MongoDB or other endpoints. By switching to reactive you can get more out of the applications that support reactive from end-to-end. That includes MongoDB and REST calls. (Not sure about SOAP, but you don't want to do SOAP anyway.)

I'd go in two phases. One phase is splitting up the application into microservices. The other phase is switching to reactive microservices. You could do these two phases in either order, but doing them in this order allows you to more gradually do the reactive migration. Otherwise, there are probably lots of components involved that need to be migrated together due to internal method signatures changing. If you do it after the split, you can do the reactive migration one microservice at a time (or perhaps some in parallel if the capacity allows it).

Another advantage of the reactive migration after the split: Microservices that use non-reactive back-ends (e.g. RDBMs) can simply be skipped. Sure, you can add webflux etc, but there will still be waiting involved at the back-end layer.
World domination requires a hollowed out volcano with good submarine access. Tiny ads are optional.
the value of filler advertising in 2021
    Bookmark Topic Watch Topic
  • New Topic