Quarkus reactive programming support about generator-jhipster-quarkus HOT 11 OPEN

@danielpetisme @joewhite101
I suggest to remove this feature from the 1.0.0 milestone. The effort needed seems to be too high.

For me, it makes sens to have a first release without reactive programming and define a plan for next version, adding this feature step by step.

WDYT?

from generator-jhipster-quarkus.

Thank you 👍🏻
These are great advice and starter points!

I'll start looking at the blueprint code and Quarkus.

I feel I should also declare that, I'm mostly familiar with JHipster generator code and Spring and am new to Quarkus framework.

from generator-jhipster-quarkus.

I can do this.

from generator-jhipster-quarkus.

The jhister cli already provides a reactive option.. we have only to add related templates for the generic app (for data layer we have to refer to the other issues)

from generator-jhipster-quarkus.

You right, is 100% templates.

Couple of pointers:
https://quarkus.io/guides/reactive-routes
https://quarkus.io/guides/reactive-sql-clients

Quarkus "reactivity" relies on Vert.x but there is a "callback-free" API for the Web layer so I propose to focus on this one first.

Ping me if you need help, I have couple of contacts.

from generator-jhipster-quarkus.

Moving to reactive is a major step.
Where web and service are quite easy to migrate, data is way more tricky.
As for now, Quarkus does not provide a "reactive" ORM. This means for the application developer to write the CRUD SQL statements manually and for a code generator like JHipster... well to actually generate those queries (which is basically the job of the ORM 🤔 ).

You get my +1 to postpone reactive to a post-1.0 realease. IMHO, concerning database access we should definitively wait for a native support from Quarkus or give a very high bounty.

from generator-jhipster-quarkus.

I'm totally aligned with that, let's remove from 1.0.0.

from generator-jhipster-quarkus.

Interested in working on this

from generator-jhipster-quarkus.

feel free @vivekmore
I think @danielpetisme already prepare the field by creating partials. Anyway, we should avoid the mess we have on the official JHipster project mixing reactive and not in the same templates (as most as possible).

from generator-jhipster-quarkus.

Thanks @avdev4j
I just wanted to make sure someone isn't already working on it.

In addition to the partials, could you share any information that could help me get started on this?

from generator-jhipster-quarkus.

Hi,

I started a long time ago but I crash my machine and lost the code (yes it happens in real life...).
Anycase, feel free to progress on this one.

A couple of advice:
1- isolate the imperative and reactive code in separate partials. I would recommend to isolate in a per method granularity (like list_imperative.ejs and list_reactive.ejs it's way easier to debug.

2- For now, do not try to have ordered imports, let the first prettier Java execution trigger at the code generation handle that for you

3- When using mutiny, queries are composable. I would suggest to made small human-readable queries and then compose them. JHipster Spring reactive tend to have a huge block that is hard to troubleshoot, please break down in smaller blocks.

4- Mutiny has no Uni implicit null filtering. If you want to prevent NPE, you need to eagerly filter the null value and throw the exception to fail fast.

Let me know if you need more guidance, I would do my best to help you.

from generator-jhipster-quarkus.