|
|
|
@@ -0,0 +1,60 @@
|
|
|
|
|
# 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.
|