Is Reactive support worth the maintenance cost?

[deepu105]

In the light of project Loom, use cases for Reactive will drastically go down. Hence is Reactive support still worth the maintenance cost? It is by far the most maintenance intensive option as almost all of the backend files need a reactive copy to be maintained. What do you all think @jhipster/developers ?

If course we would have to keep Gateways reactive due to spring cloud. But I think that can be achieved without making the entire application reactive

[pascalgrimaud]

In my personal opinion, Reactive option is just for hype and demo. I didn't see the use in my projects for my customers, the last years.

I would suggest to move to blueprint for users who want to use and maintain it

[cbornet]

Do we have stats on the generation of reactive apps ?

[deepu105]

@jdubois knows how to get those stats probably

[mraible]

FWIW, Spring Cloud Gateway does have a Spring MVC version in 4.1.0-M1. I asked @spencergibb, and he said it wouldn't be released until December.

[niceguisuku]

I voted no. I have not reviewed the jhipster code yet but the curious question would be that is it possible to add reactive support as a pluggable module or design such that developers can pick and choose reactive support for various modules / components within the entire code?

[schrepfler]

While Loom might address some difficulties of programming with Reactive APIs it's still unclear how will this deal with issues like back pressure and generally work with streams which are useful in many domains and the main reason why people select these flavours. I would hope providing a pattern for this in the jhipster space is useful and shouldn't be too hard considering Spring still provides the two flavours of apps. In the end, you should ask your community.

[yacosta738]

I really prefer reactive approach

[ice09]

In the light of project Loom, use cases for Reactive will drastically go down. Hence is Reactive support still worth the maintenance cost? It is by far the most maintenance intensive option as almost all of the backend files need a reactive copy to be maintained. What do you all think @jhipster/developers ?

If course we would have to keep Gateways reactive due to spring cloud. But I think that can be achieved without making the entire application reactive

I messed up, I wanted to vote "yes", but cannot change my wrongly chosen "no". Focus on other functionality, reactive is not worth it in the light of loom.

[ahamdi]

@ice09 I believe you voted correctly. Yes means the reactive support could be removed.

[ice09]

Yes, that's what I meant. I want the reactive support to be removed :)

[OmarHawk]

same here :D I just answered the question in the title, but the poll asks the opposite

[atomfrede]

I would say let's keep the reactive gateway. For reactive apps it's a good question. I tend towards no (until we have some numbers maybe) because I would suspect most people to use non-reactive option. I am not sure we can move it to a blueprint that easily, I think we have done some things which (at least when we introduced reactive support) where not possible.

[Tcharl]

Maybe we can leverage the 'reactive pain' by switching to the architecture modulith: the real hard stuff on the generator is to maintain the 'jpa-like' reactive queries which are really clunky (and not so far to be a reactive antipattern).
Maintaining reactive at the core level also bring some nice side effect: any contributor has to think about modular template and code design upfront. On the other side, I agree that it dramatically slows down the core generator delivery (it raises the bar so high to produce something that works, should even be worse for newjoiners)

[deepu105]

its so tempting to drop a lot of (low use) features to make the generator more maintainable

[michael-simons]

I’m as a maintainer of a reactive database layer am completely torn. I think we created a real good module that tackles the challenge of retrieving graph data row wise and then recreating the graph locally. But: it comes with a costs. Requires normalization during transports, prevents some better query patterns etc. enables other good use cases.

For the users it’s equally hard to maintain proper reactive patterns.

Its high maintaince costs only justifiable in some use cases. for our project we definitely won’t drop it, it is in production in several high load scenarios, for an application generator that’s much more common / generic approach I would be more on the “move to plugin / blueprint” side of things.

[deepu105]

I'm strongly for dropping Reactive support as soon as we have a non reactive Spring cloud gateway. For those who is in favor of keeping the support, please do say why you think its worth the maintenance cost, coz currently the templates are twice as complex due to this one option which IMO is not even used that much

[deepu105]

@jhipster/developers please add your valuable votes

[jdubois]

Concerning stats, I couldn't find anything, either in our older Google Analytics reports, or our newer data in start.jhipster.tech. It's sad, but I don't think we tracked that option at all.
I have not seen this option being widely used, and it makes the templates super complex, so I voted for removing it.

[mraible]

I voted No because I use reactive a lot in blog posts, demos, and presentations. That's production for me since I'm mostly an example programmer these days. I've had a lot of positive feedback on my reactive content.

[Tcharl]

@jhipster/developers please add your valuable votes

My vote would be for the in-between: to support reactive in the area it is useful following the reactive paradigms/best patterns

• Keep the gateway reactive, and forbid any entity but potentially user/role there (as its name says, it's a gateway, not something made to store anything but authorizations) so only DTO/VO aggregate will be supported there
• At the microservice/monolith level, only support pure reactive POJO's (DTO and entity) without any relationship support: developper will have to implement his own reactive mappers for advanced use cases, but it is where jhipster shines here (to be able to support customization)

[atomfrede]

I would vote no right now as I also think reactive gateway (as the only gateway type) is a good thing. For normal applications I would mostly vote yes.