Thoughts on Agrest 5.0

8 views
Skip to first unread message

Andrus Adamchik

unread,
Nov 14, 2021, 8:44:05 AM11/14/21
to Agrest Framework User Group
For some time we've envisioned (and worked towards) Agrest as a generic graph query protocol / abstract engine independent from REST serialization technology or a specific data backend. The recent move of JavaEE to Jakarta (resulting in the change from "javax.ws.rs" to "jakarta.ws.rs" discussed here recently) gives us yet another motive to prioritize this work.

The refactoring needed to be done to the Agrest core to finally get there requires a major version increase. So I figured I might collect my ideas for Agrest 5.0:

1. Minimize the existing footprint. Remove the following modules:

* agrest-client: rarely used (Agrest is usually accessed from JS), barely evolved, and adversely affects our modularity decisions
* agrest-openapi-designfirst: Design-first, while an attractive proposition for API docs, is nearly impossible to support properly, and is impractical at the moment. We support code-first approach via "agrest-openapi" instead.

2. Switch to Java 11. About time to stop supporting Java 8.

3. Remove dependency on "cayenne-di": Agrest is not that big to have an embedded injection engine, and getting rid of the final direct dependency on Cayenne is the goal. Let's just keep a decent builder API for extensions, and ServiceLoader - for pluggable backends.

4. Reorganize the modules so the core is free of backend or frontend assumptions. Shorten module names along the way:

* annotations (to annotate object models without bringing runtime in the picture)
* core (dependency-free core; no JAX-RS, none or minimal Cayenne dependency)
* rest-jakarta (Bindings to run Agrest on Jakarta REST API, e.g. Jersey 3)
* rest-jaxrs (only if we care to support legacy JAXRS)
* backend-cayenne (pluggable Cayenne backend for Agrest; JAXRS and Jakarta bindings can also be bundled using "provided" dependency mechanism)
* openapi
* sencha (legacy Sencha extensions ... may decide to finally drop it)

So a typical user would import "io.agrest:rest-jakarta", "io.agrest:backend-cayenne", and possibly "io.agrest:openapi". And anyone can build adapters for Spring REST, JPA backend, etc.

Andrus


Reply all
Reply to author
Forward
0 new messages