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

DB refactor #1418

Open
MiniDigger opened this issue Nov 3, 2024 · 0 comments
Open

DB refactor #1418

MiniDigger opened this issue Nov 3, 2024 · 0 comments
Labels
1. api This issue/pr relates to an issue/change on the api 1. feature New feature or request 2. backend This issue/pr relates to an issue/change on the backend discussion Issue meant for discussion hangar-team Pre-discussed and well-made PRs might be approved, but is preferably done by collaborators help wanted Extra attention is needed

Comments

@MiniDigger
Copy link
Member

MiniDigger commented Nov 3, 2024

the current DB structure is a mess and causes our queries to be a mess which causes everything to be slow and makes changes hard.
I propose completely wiping the DB and starting from scratch (while obviously migrating data over, most likely by having a new DB in postgres and setting hangar into read only while migration happens).

while that obviously seems super dauting and a giant task, I propose refactoring the backend to adhere to domain driven development (DDD) principles, basically splitting everything up into domains (users, projects, versions, pages, jobs, etc) and giving each domain ownership over its tables.
then we can rewrite stuff one by one.

ideally, the domains only expose domain objects, not DB objects, so internal changes in a domain in the future will have no affect on other domains.

I envision a facade infront of a each domain that will only expose strictly typed interfaces.
so a VersionFacade would have a methods getVersion()Version, getVersionWithDependencies()VersionWithDependencies, getVersionWithPlatforms()VersionWithPlatforms, getVersionFull()FullVersion etc., all backed by an internal VersionImpl class that has all these fields.

The facade could also implement all security stuff (if that isnt done in the db queries) and hiding certain fields for certain callers (i.e. IDs shouldn't be exposed in the public api)

list of "requirements":

  • need a way to not repeat part of queries all the time
  • one rest request ideally is one query
  • don't join tables we may need for filters when those filters arent used (or would select everything)
  • denormalize some tables to keep joins to a minimal (i.e. the whole version mess) or use materialized views?
@MiniDigger MiniDigger added 1. api This issue/pr relates to an issue/change on the api 1. feature New feature or request 2. backend This issue/pr relates to an issue/change on the backend discussion Issue meant for discussion hangar-team Pre-discussed and well-made PRs might be approved, but is preferably done by collaborators help wanted Extra attention is needed labels Nov 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
1. api This issue/pr relates to an issue/change on the api 1. feature New feature or request 2. backend This issue/pr relates to an issue/change on the backend discussion Issue meant for discussion hangar-team Pre-discussed and well-made PRs might be approved, but is preferably done by collaborators help wanted Extra attention is needed
Projects
Status: New
Development

No branches or pull requests

1 participant