• 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
  • Tim Cooke
  • Liutauras Vilda
  • Jeanne Boyarsky
Sheriffs:
  • Paul Clapham
  • Rob Spoor
  • Junilu Lacar
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Piet Souris
  • Carey Brown
Bartenders:

Reactive Spring

 
Greenhorn
Posts: 9
  • 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.

 
Bartender
Posts: 2265
13
  • 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.
 
Sheriff
Posts: 22716
129
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.
 
reply
    Bookmark Topic Watch Topic
  • New Topic