Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Investigate feasibility of creating a Quarkus extension for DataNucleus #1231

Open
2 tasks done
nscuro opened this issue Apr 24, 2024 · 1 comment
Open
2 tasks done
Labels
component/api-server p3 Nice-to-have features size/L High effort spike/research Requires more research before implementation

Comments

@nscuro
Copy link
Member

nscuro commented Apr 24, 2024

Current Behavior

Having to deal with multiple tech stacks (Alpine for API server, Quarkus for all other services) poses some challenges. It would be great if we could eventually converge them all to at least use the same framework.

Having all of the services use the same tech stack could potentially enable us to structure the project as modular monolith, such that users can decide if they prefer to deploy a single application, or multiple.

The API server largely uses standard Java EE concepts and as such would be relatively easy to port to Quarkus. The only outlier being the persistence framework, DataNucleus. There is no Quarkus extension for it (quarkusio/quarkus#1908). However, it might be feasible to create one.

Proposed Behavior

Investigate how feasible it is to create a Quarkus extension for DataNucleus: https://quarkus.io/guides/writing-extensions

Checklist

@nscuro nscuro added p3 Nice-to-have features size/L High effort component/api-server spike/research Requires more research before implementation labels Apr 24, 2024
@nscuro
Copy link
Member Author

nscuro commented Apr 24, 2024

An alternative approach would be to migrate the persistence code to Hibernate instead. Looking at how much code is involved in the hibernate-orm extension, I'm not sure doing the same for DataNucleus is something we can realistically do and maintain on our own.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component/api-server p3 Nice-to-have features size/L High effort spike/research Requires more research before implementation
Projects
None yet
Development

No branches or pull requests

1 participant