Move towards a MVC architeture #60

New issue

Open

opened 2026-08-15 11:40:56 +00:00 by theis · 0 comments

theis commented

2026-08-15 11:40:56 +00:00

Owner

This is the plan:
How far should the service-layer split go on branch 05?
OIDC only (Recommended)

Where should the new service live?
backend/internal/service/oidc (Recommended)

How should the service expose results to the handler?
Typed results + handler does HTTP (Recommended)

Should the service call postgres.Store directly, or go through an interface?
Interface in service package (Recommended)

HandleOIDCCallback is the long one. How should it be split?
Orchestrator + private steps (Recommended)

Branches 06/07 add linking/logout on top of oidc.go. How should we account for that?
Design service API so 06/07 extend it (Recommended)

05 is still based on old stack tip. How do you want the refactor delivered?
Rebase 05 onto main first, then refactor (Recommended)

I have an issue with 05. We are doing too much in the handler (functions too long, and we should not call storage operations directly from the handler, we should have service functions in between, so we get closer to a MVC approach) This is the plan: How far should the service-layer split go on branch 05? OIDC only (Recommended) Where should the new service live? backend/internal/service/oidc (Recommended) How should the service expose results to the handler? Typed results + handler does HTTP (Recommended) Should the service call postgres.Store directly, or go through an interface? Interface in service package (Recommended) HandleOIDCCallback is the long one. How should it be split? Orchestrator + private steps (Recommended) Branches 06/07 add linking/logout on top of oidc.go. How should we account for that? Design service API so 06/07 extend it (Recommended) 05 is still based on old stack tip. How do you want the refactor delivered? Rebase 05 onto main first, then refactor (Recommended)