4ntoine
4ntoine

Reputation: 20410

Quarkus without heavy dependencies on Panache?

I like the idea of using JAX-RS in Quarkus as it will make the code not dependent on framework implementation. However when it comes to DB we're proposed to use "Panache" and extend the DB entities from PanacheEntity. I guess it's very handy and good for AOT work (what is basically Quarkus is trying to do) and simplifies Quarkus work a lot, but it introduces heavy dependency on particular implementation and we can't use pure JPA modules because of that.

This conflicts with "clean architecture" and make testing of such DB module complicated [if possible at all]. Let's say i'd like to be able to use the same DB module (using pure JPA annotations only) for both Spring and Quarkus-based app modules. It forces me to duplicate the code or cheat in terms of design purity.

Is there any possibility to use pure JPA annotations for persistence and probably pay the price with plugins (that modify the code during compilations) or by using of ORM framework(s) that do not do runtime bytecode modification/use reflection? Any examples?

PS. Congrats on 1.0 release! Good job, Quarkus team.

Upvotes: 6

Views: 3377

Answers (2)

theoblade
theoblade

Reputation: 31

First of all, I totally agree. I feel it's going against the idea of spec first.

But I have the feeling that the idea is to extend Quarkus reactive capabilities which they already admitted is currently only available for REST resources.

If you stick on JPA I guess you won't have access to Mutuniy features, unlike if you use Panache and Hibernate Reactive.

Upvotes: 0

Ladicek
Ladicek

Reputation: 6577

Panache is purely optional and you can stick with plain JPA, as documented in https://quarkus.io/guides/hibernate-orm.

If you could explain why you think you have to use Panache, I believe that would be interesting for the Quarkus team.

Upvotes: 11

Related Questions