logicspike/docs

Authentication & Team

Architecture Analysis: Dedicated Auth Service

You asked to analyze apps/manager and suggest if we should split Authentication into a separate service (apps/auth).

1. The Current & Proposed Architecture

Feature Current (apps/manager Monolith) Proposed (Split apps/auth)
Responsibility Manages Users, Tenants, Billing, AND Auth. Auth: Identity, Tokens, Security.
Manager: Tenants, Billing, Team.
Database Single DB Connection. Shared Database (likely) or distinct connections.
Registration Atomic Transaction: User + Tenant + Membership created together. Distributed: Auth creates User -> calls Manager to create Tenant.
Complexity Low. Single deployment. Medium. Two apps, inter-service communication.

2. Key Challenge: The "Registration Transaction"

Currently, when a user signs up, we execute a single db.transaction():

  1. Insert User.
  2. Insert Tenant (Workspace).
  3. Insert Membership (Link).

If we split services: We cannot use a database transaction across two different running applications easily.

  • Risk: apps/auth creates the User, but apps/manager fails to create the Tenant.
  • Result: User exists but has no workspace (Broken state).
  • Fix: requires complex "Saga" patterns (compensating transactions) or Event Bus.

3. Recommendation

🚀 Recommendation: Stay Monolithic (For Now)

Reason: To maintain Data Integrity and Development Speed. LogicSpike is currently in the "Building Foundation" phase. Splitting now prevents us from using simple database transactions for complex operations like Registration or "Delete Workspace" (which deletes users/auth).

🛠️ Strategic Compromise: "Modular Monolith" in apps/manager

We strictly separate the code within apps/manager.

  • src/modules/auth: ALL authentication logic.
  • src/modules/identity: User management.
  • src/modules/tenant: Workspace management.

When to Split? We should extract apps/auth only when:

  1. We have other apps (e.g., a Mobile App or Customer App) that need Auth but don't need Tenant Management.
  2. The Auth traffic scale allows it (e.g., Millions of logins vs thousands of admin actions).

4. If You Still Want to Split

If you prefer the strict separation immediately, I can design the Inter-Service Communication:

  1. Shared Database Pattern: Both services connect to the same Postgres.
    • apps/auth: Writes to users, user_auth.
    • apps/manager: Writes to tenants, memberships.
    • Transaction: We can still potentially share a transaction if we architect key libraries carefully, or we accept the "User created without Tenant" risk and handle it via UI (e.g., "Finish Setup" screen).

Decision: A. Keep Integrated (Recommended for speed/robustness). B. Split Now (Accept complexity for strict separation).

Authentication & Team