Files

T

julien 36c1fe805e refactor(routes): extract user and application routes into auth domain

Move /api/cms/user and /api/skydive/applications to a new /api/auth domain.
Users and API key applications are identity/access concerns, not CMS or
skydive content. The auth domain provides a clear boundary for future
middleware hardening (rate limiting, audit logging, etc).

docs: add ADR 0014

2026-05-01 20:43:13 +02:00

2.7 KiB

Raw Permalink Blame History

Extract user and application routes into a dedicated auth domain

Status: accepted
Date: 2026-05-01

Context and Problem Statement

User authentication/registration routes (/api/cms/user) were grouped under the CMS domain, and API key application routes (/api/skydive/applications) were grouped under the Skydive domain. Neither resource is domain-specific content: users and applications are identity and access management concerns shared across all domains.

Decision Drivers

The domain prefix should reflect what a resource is, not which feature first needed it.
/api/cms/user implies users are CMS content; /api/skydive/applications implies API keys are skydive data — both are misleading.
A dedicated auth domain makes the security boundary explicit and easier to apply targeted middleware (rate limiting, stricter CORS, etc.) in the future.

Considered Options

Keep routes in their current domains
Move only users out of CMS, leave applications in skydive
Create a dedicated auth domain for both

Decision Outcome

Chosen option: "dedicated auth domain", because both resources are identity/access concerns and grouping them together makes the API surface self-documenting.

Changes made:

src/routes/api/auth/ created with users.routes.js, applications.routes.js, and index.js
/user removed from src/routes/api/cms/index.js
/applications removed from src/routes/api/skydive/index.js
/auth domain registered in src/routes/api/index.js
Frontend user.service.ts and applications.service.ts updated: _apiDomain changed from /cms and /skydive to /auth

Resulting routes: /api/auth/user/* and /api/auth/applications/*.

Positive Consequences

API domain structure matches resource semantics — auth concerns are isolated from content and feature domains.
A single place to tighten auth-specific middleware (rate limiting, IP allowlists, audit logging) without touching other domains.

Negative Consequences

Breaking change on the API surface — any client other than the Angular frontend calling the old paths must be updated.

Pros and Cons of the Options

Keep routes in current domains

Good, because no migration effort.
Bad, because the domain prefix actively misleads — users are not CMS content, applications are not skydive data.

Move only users out of CMS

Good, because smaller change.
Bad, because applications in skydive remains wrong, and two related resources end up in different places.

Dedicated auth domain

Good, because both resources land where their semantics say they belong.
Good, because the auth boundary is explicit and ready for future hardening.
Bad, because it is a breaking change requiring a coordinated update of all consumers.

2.7 KiB Raw Permalink Blame History