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

Evolve backend-core to new major version #98

Open
mlopezFC opened this issue Jun 30, 2024 · 0 comments
Open

Evolve backend-core to new major version #98

mlopezFC opened this issue Jun 30, 2024 · 0 comments
Labels
question Further information is requested

Comments

@mlopezFC
Copy link
Member

When we started to give shape to this project, 4 years ago, the situation of what was available was a little bit different as it is today. So I'm thinking that we have to analyze what this set of libraries is offering and focus only on things that make it different compared to other things that are available in the open source world.
What I think that is valuable from this project is basically focusing on offering code re use for CRUD functionalities, that can be used in project with strict separation of concerns.
At the same time, it would be great to avoid reinventing the wheel, and re use things that are now available and widely adopted like Spring Data's CrudRepository and ease things so Spring Data can be used.
Why not just use Spring Data alone? .. well, basically because it enforces your services code to depend on data layer objects, and that is something that we prefer to avoid so each layer code is more separated (discussion of why we want that might be out of the scope of this ticket).
So this is what I'm proposing for the next big version of the libraries:

  • Consider modifying the API of our mixin interfaces so they can be compatible with Spring Data's Crud Repository
  • Avoid providing our own implementation of the crud repositories and use spring data's implementation
  • Maintain the QuerySpec feature given that allows the definition of what and how we want to query from the data layer avoiding having to depend on data related object such as jpa annotations
  • Make things super easier if we want to add specific dao methods outside the regular CRUD related dao operation, by using things like JPA Query Methods
  • Seize the opportunity of introducing breaking changes like QuerySpec builder and other things that I don't remember right now
  • Maintain strict separation of layers, so I don't need to carry data related transitive dependencies to the service or presentation layer, if I want to execute a new complex method to retrieve or persist data
  • Transfer completely the conversion of persistent entities to the data implementation layer, so we avoid forcing the transitive dependency of persistent annotations to the other layers.

Let's discuss, because I might be missing something here.

@mlopezFC mlopezFC added the question Further information is requested label Jun 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

1 participant