Architecture: How should authentication be split for performance and maint...

Documentation for Sessions

🏗️ Architecture: How should authentication be split for performance and maint...

Date: 2026-03-14
Time: 20:03:16 UTC
Session: gspace1-222.2
Agent: angular
Confidence: 95%
Status: ✅ Documented

📋 Decision Context

Question:

How should authentication be split for performance and maintainability?

Task: Not specified

🎯 Decision Made

Chosen:

Split into @auth-core (always) + @auth-ui (lazy)

Options Considered:

Single auth library with lazy routes
Split into @auth-core (always) + @auth-ui (lazy)
Keep monolithic auth-ui with ESLint exceptions

💭 Reasoning

Root cause: auth-ui mixed always-needed infra (AuthService, guards) with heavy UI (Login, Register). Loading all on bootstrap slowed startup. Split gives: (1) @auth-core = services, guards, interceptors, UserMenu — always loaded, small; (2) @auth-ui = route components only — lazy via loadComponent. Superior because: clear separation of concerns, smaller initial bundle, no ESLint exceptions needed. Would be wrong if: we needed auth-ui components in app shell (we do not — UserMenu is in auth-core). Early warning: any new auth infra added to auth-ui instead of auth-core.

📁 Files Involved

libs/libs-foundational/auth-core/src/index.ts
libs/libs-ui/auth-ui/src/index.ts

🔗 Related

Decision ID: dev_1773518596227_xsk1vw5
Session: 222
Workspace: gspace1

Auto-generated by MCP Smart Consolidation