Generator-jhipster: Spring 5 update

[sendilkumarn]

Since Spring 5 is around the corner,

can we add in an option to create reactive non-blocking or to use them by default (since it supports mix and matching the reactive & non-reactive things)

Spring 5 Blog here

@jhipster/developers what you guys think about it?

[jdubois]

For me this is going to be an option. There are many cases where "reactive" do not work well:

• When using JDBC (as the driver is blocking, as well as probably the database underneath), so this is just going to flood your system and make it crash (aka "why the Play! demos are total bullshit")
• When using a reactive database, it also depend: for me there is little interest with Cassandra (and I've been using their reactive driver for years with plain old Spring MVC REST).
• The only good use case I have, and my neighbour at work is doing exactly that, is when using MongoDB. Then, of course, you're going to have consistency issues if you're not careful (well, I would argue that with MongoDB you will always have consistency issues, whatever you do!). So this needs to be solved at the business level, and that's usually quite annoying (from a business as well as a tech perspective), and at least that's quite costly to manage.

In the end, it depends on the technology stack you use, your goal (if you want easy debugging and easy consistency, just use a blocking transaction), your performance aim (reactive is for scalability, not for performance), and of course the business team (as this will impact them).

[xetys]

I think we definitely should go with Spring 5, as it would be out-dated if we stuck on version 4.

However, IMHO reactive programming brings a notable complexity into development, where the true benefits of it often don't worth the cons. If performance is the crucial attribute, a system must fit good in, then reactive programming is the way to go. But when the task is simply to build a microservice with API, reactive is overpowered and lead to less productivity. I also have my doubts with Rx in angular. They just made that pattern a fact of architecture, where a lot old-schoolish front devs have a lot PITA to face.

The question is more, just to add Spring 5 deps and some of its new features, or redesign our application to reactive types from front till end? The second option would scale the learning curve to a JHipster newcomer a lot. Supporting both, blocking and non-blocking version of an application would be hard work for us, too.

For me, I am not sure, if enforcing reactive to our users is a good idea, even if this is somehow logically. We are already enforced to do so in angular.

[deepu105]

IMO we should definitely move to Spring 5 but only once Spring boot 2 is
ready. So ideally it will be migration to SPring boot 2
As for Reactive I agree to what Julien and David said its not worth the
pain. But ofcourse it can be a new option.

What I would really like to do as JHipster 5 would be to support React and
make our generated code easily extensible so that upgrades are smoother and
less dependent on git magic. But thats a whole new discussion

Thanks & Regards,
Deepu

On Mon, May 15, 2017 at 5:08 PM, David Steiman [e-mail]
wrote:

I think we definitely should go with Spring 5, as it would be out-dated if
we stuck on version 4.

However, IMHO reactive programming brings a notable complexity into
development, where the true benefits of it often don't worth the cons. If
performance is the crucial attribute, a system must fit good in, then
reactive programming is the way to go. But when the task is simply to build
a microservice with API, reactive is overpowered and lead to less
productivity. I also have my doubts with Rx in angular. They just made that
pattern a fact of architecture, where a lot old-schoolish front devs have a
lot PITA to face.

The question is more, just to add Spring 5 deps and some of its new
features, or redesign our application to reactive types from front till
end? The second option would scale the learning curve to a JHipster
newcomer a lot. Supporting both, blocking and non-blocking version of an
application would be hard work for us, too.

For me, I am not sure, if enforcing reactive to our users is a good idea,
even if this is somehow logically. We are already enforced to do so in
angular.

—
You are receiving this because you are on a team that was mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jhipster/generator-jhipster/issues/5767#issuecomment-301504813,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABDlF3GCybd66h0vM9218hoPaQ7ZN90qks5r6GqLgaJpZM4NbOYP
.

[cbornet]

Just wanted to share that there are great use-cases for FRP especially on client-side and when dealing with streams. On client-side it makes it easy to launch multiple queries in parallel and to zip the results as they arrive. For streams and anything that does a PUB/SUB, it's a natural fit (using the reactive-streams extension to get backpressure and prevent flooding the subscriber). For instance I see it as a very useful way of programming for things such as gRPC which has bidirectional streaming over HTTP2.
That said, the gain when using it on non streaming server endpoints is not clear to me either.

[cbornet]

Also note that you don't have to wait for Spring5's WebClient to benefit from FRP, spring-cloud's HystrixCommand is already reactive !

[jdubois]

I think we all agree here, and anyway we need to wait for Spring Boot 2.0 as @deepu105 said, so I'm closing this.

[Tcharl]

True Hipsters wanna use reactive ;-)

[gzsombor]

Handling transactions / JPA entity cache could be very tricky with reactive streams. I don't think, it would made sense in that case.