search

jhipster / generator-jhipster-quarkus

Quarkus blueprint for JHipster
https://www.jhipster.tech/blueprints/quarkus/
Apache License 2.0
140 stars 55 forks source link

Quarkus reactive programming support #3

Open danielpetisme opened 4 years ago

danielpetisme commented 4 years ago

Quarkus proposes a neat reactive programming model (which can be used side by side with the imperative model).

The objective is to propose to the user to choose the programming model and generate the according templates.

ghost commented 4 years ago

I can do this.

ghost commented 4 years ago

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)

danielpetisme commented 4 years ago

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.

avdev4j commented 3 years ago

@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?

danielpetisme commented 3 years ago

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.

avdev4j commented 3 years ago

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

vivekmore commented 2 years ago

Interested in working on this

avdev4j commented 2 years ago

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).

vivekmore commented 2 years ago

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?

danielpetisme commented 2 years ago

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.

vivekmore commented 2 years ago

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.