egullickson/motovaultpro
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
3693ce576195cfde7c490aaed69bedf6255e6efb
motovaultpro/docs/TENANT-REMNANTS-ANALYSIS.md
Eric Gullickson 3693ce5761 Docs Cleanup
2025-11-02 10:34:43 -06:00

14 KiB
Raw Blame History

MotoVaultPro Multi-Tenant Architecture Remnants Analysis

Date: November 2, 2025 Status: Very Thorough Exploration Finding: Multi-tenant refactor complete in application code, but orphaned platform services and configuration remnants exist

Executive Summary

The migration from 14-container multi-tenant architecture to 6-container single-tenant architecture is CLEAN at the application level but has ORPHANED SERVICES AND CONFIGURATION that should be addressed:

Key Findings:

  1. ✅ Application code: CLEAN - No tenant_id references in backend/src or frontend/src
  2. ✅ Core middleware: DELETED - tenant.ts and tenant.ts middleware files removed
  3. ✅ Database schema: CLEAN - No tenant_id columns in application tables
  4. ⚠️ Configuration: PARTIAL - Legacy references in config and environment variables
  5. ⚠️ Platform services: ORPHANED - mvp-platform-services/tenants and landing still present and deployed
  6. ⚠️ Documentation: STALE - References to removed components still exist

Detailed Findings by Category

1. CODE REFERENCES TO TENANT (PRIORITY: LOW - Cosmetic)

Backend Application Code

Status: ✅ CLEAN

  • ✅ 0 occurrences of tenant_id in /backend/src/**/*.ts
  • ✅ 0 occurrences of tenantId in /backend/src/**/*.ts
  • ✅ 0 occurrences of tenant middleware imports in application code
  • ✅ auth.plugin.ts (line 1-93) - JWT plugin only extracts sub and roles, no tenant_id
  • ✅ app.ts (line 1-136) - No tenant middleware registration, no tenant routes
  • ✅ Core README.md - References deleted tenant.ts (should be removed from docs)

Findings:

  • File: /Users/egullickson/Documents/Technology/coding/motovaultpro/backend/src/core/README.md
    • Line 7: "- tenant.ts — Tenant configuration utilities"
    • Line 18: "- middleware/tenant.ts — Tenant extraction/validation"
    • Assessment: Documentation references non-existent files (misleading, not a code issue)

2. ENVIRONMENT VARIABLES (PRIORITY: MEDIUM - Confusing)

Active Environment Variables with "TENANT"

File: /Users/egullickson/Documents/Technology/coding/motovaultpro/.env.development

  • Line 10: VITE_TENANT_ID=admin
  • Line 17: TENANT_ID=admin
  • Issue: These variables are defined but NOT USED in the application
    • Frontend build doesn't reference VITE_TENANT_ID (verified: 0 occurrences in frontend/src)
    • Backend doesn't read TENANT_ID (verified: no usage in backend code)
    • Docker-compose only references these in frontend build args (line 51)
    • Assessment: Cargo-cult configuration - leftover from multi-tenant era

File: /Users/egullickson/Documents/Technology/coding/motovaultpro/docker-compose.yml

  • Line 51: VITE_TENANT_ID: ${TENANT_ID:-admin} - Frontend build arg that's never used
  • Assessment: Dead configuration, no impact but confusing

File: /Users/egullickson/Documents/Technology/coding/motovaultpro/config/app/production.yml.example

  • Line 4: tenant_id: admin - Configuration schema still includes this
  • Assessment: Example file only - not loaded at runtime but misleading for ops

3. DATABASE SCHEMA (PRIORITY: NONE - Clean)

Status: ✅ VERIFIED CLEAN

  • Checked application PostgreSQL schema via migrations in /backend/src/features/**/*migrations/*.sql
  • ✅ No tenant_id columns in any application tables
  • ✅ All user data properly scoped to user_id
  • ✅ Sample tables verified:
    • vehicles - uses user_id, not tenant_id
    • fuel_logs - uses user_id, not tenant_id
    • documents - uses user_id, not tenant_id
    • maintenance_records - uses user_id, not tenant_id

4. API ENDPOINTS (PRIORITY: NONE - Clean)

Status: ✅ VERIFIED CLEAN

  • ✅ No /tenant/ or /tenants/ endpoints in application code
  • ✅ No tenant-management routes registered
  • ✅ All API routes are feature-based: /api/vehicles, /api/documents, /api/fuel-logs, etc.
  • ✅ User scoping is implicit via JWT sub claim in request.user.sub

5. CONFIGURATION FILES (PRIORITY: MEDIUM - Clean up needed)

Production Config

File: /Users/egullickson/Documents/Technology/coding/motovaultpro/config/app/production.yml.example

server:
  port: 3001
  tenant_id: admin  # <-- UNUSED, should remove
  • Line 4: tenant_id: admin
  • Issue: Configuration key exists but is never read
  • Impact: Example only, but misleading for operators
  • Recommendation: Remove this line

Platform Config

File: /Users/egullickson/Documents/Technology/coding/motovaultpro/config/platform/production.yml

  • No tenant references found in platform configuration
  • ✅ Platform (vehicles API) is clean

6. MIDDLEWARE FOR TENANT ISOLATION (PRIORITY: NONE - Deleted)

Status: ✅ DELETED

  • ✅ /backend/src/core/middleware/tenant.ts - DOES NOT EXIST
  • ✅ /backend/src/core/config/tenant.ts - DOES NOT EXIST
  • ✅ /backend/src/features/tenant-management/ - DOES NOT EXIST
  • ✅ No tenant middleware imports in app.ts
  • ✅ No tenant middleware registration in app.ts

7. MULTI-TENANT PLATFORM SERVICES (PRIORITY: HIGH - Orphaned)

CRITICAL: Orphaned Platform Services Still Running in Production

Status: ⚠️ ORPHANED - These services are built, deployed, and running but NOT USED

mvp-platform-services/tenants

Location: /Users/egullickson/Documents/Technology/coding/motovaultpro/mvp-platform-services/tenants/

  • Purpose: Multi-tenant management, signup approvals (NOT NEEDED - single-tenant now)
  • Status: Still present and potentially running
  • Files:
    • api/main.py (100+ lines) - FastAPI application for tenant management
    • sql/schema/001_tenants_schema.sql - Tenant database schema (separate from app)
    • AUTH0-CONFIG.md - Multi-tenant Auth0 configuration

Code References:

  • File: api/main.py - Complete multi-tenant service with:
    • Models: TenantCreate, TenantResponse, SignupRequest, SignupResponse
    • Endpoints: GET /api/v1/tenants/{tenant_id}, PUT /api/v1/tenants/{tenant_id}, POST /api/v1/tenants/{tenant_id}/signups
    • Database: CREATE TABLE tenants, CREATE TABLE tenant_signups
    • Auth0 integration: Extracts tenant_id from Auth0 JWT claims

Assessment:

  • Problem: This entire service is multi-tenant focused and NOT NEEDED in single-tenant architecture
  • Impact: Resource waste (container, database schema, memory), confusion for future maintainers
  • Priority: HIGH - Should be deleted
mvp-platform-services/landing

Location: /Users/egullickson/Documents/Technology/coding/motovaultpro/mvp-platform-services/landing/

  • Purpose: Multi-tenant landing/signup page for different tenants
  • Status: Still present and potentially running
  • Files:
    • src/App.tsx - Routes to /signup/:tenantId
    • src/components/TenantSignup.tsx - Tenant signup flow (references VITE_TENANTS_API_URL)
    • Dockerfile - Builds landing page service

Code References:

  • File: src/App.tsx

    • Line 12: <Route path="/signup/:tenantId" element={<TenantSignup />} />
    • Purpose: Route for tenant-specific signup (NOT NEEDED)

  • File: src/components/TenantSignup.tsx

    • Line 23: ${import.meta.env.VITE_TENANTS_API_URL}/api/v1/tenants/${tenantId}
    • Purpose: Calls orphaned tenants service API

Assessment:

  • Problem: This landing page is for multi-tenant signup flow (register new tenant)
  • Impact: Resource waste, confusion about signup flow (single-tenant should have simpler flow)
  • Priority: HIGH - Should be deleted or consolidated into main landing

8. ORPHANED ENVIRONMENT VARIABLE REFERENCES (PRIORITY: HIGH)

VITE_TENANTS_API_URL

Locations:

  1. /Users/egullickson/Documents/Technology/coding/motovaultpro/mvp-platform-services/landing/src/vite-env.d.ts

    • Line: readonly VITE_TENANTS_API_URL: string
    • Issue: Defined but landing page is not used

  2. /Users/egullickson/Documents/Technology/coding/motovaultpro/mvp-platform-services/landing/Dockerfile

    • ARG VITE_TENANTS_API_URL
    • ENV VITE_TENANTS_API_URL=${VITE_TENANTS_API_URL}
    • Issue: Build arg that's not used

  3. /Users/egullickson/Documents/Technology/coding/motovaultpro/docker-compose.yml

    • Referenced in platform service environment setup (no longer deployed)
    • Issue: Docker-compose removed platform-tenants service but vars might still be elsewhere

VITE_TENANT_ID

Locations:

  1. /Users/egullickson/Documents/Technology/coding/motovaultpro/.env.development

    • Line 10: VITE_TENANT_ID=admin
    • Issue: Never used in frontend code

  2. /Users/egullickson/Documents/Technology/coding/motovaultpro/docker-compose.yml

    • Line 51: VITE_TENANT_ID: ${TENANT_ID:-admin}
    • Issue: Dead build arg

9. DOCUMENTATION WITH STALE REFERENCES (PRIORITY: LOW - Maintenance)

Files with tenant references:

  1. File: /Users/egullickson/Documents/Technology/coding/motovaultpro/backend/src/core/README.md

    • Lines 7, 18: References deleted tenant.ts files
    • Assessment: Misleading documentation
    • Fix: Remove lines 7 and 18

  2. File: /Users/egullickson/Documents/Technology/coding/motovaultpro/backend/src/features/documents/README.md

    • Line 24: References core/middleware/tenant
    • Assessment: Outdated dependency documentation
    • Fix: Remove tenant middleware reference

  3. File: /Users/egullickson/Documents/Technology/coding/motovaultpro/docs/redesign/ (multiple files)

    • These are DESIGN DOCUMENTS describing the refactoring process
    • Assessment: Historical documents, not application code
    • Fix: Archive or document clearly as historical

Summary Table

Category Finding Status Priority Impact
Backend Code No tenant_id references CLEAN NONE N/A
Frontend Code No tenant_id references CLEAN NONE N/A
Database Schema No tenant_id columns CLEAN NONE N/A
API Endpoints No /tenant/ routes CLEAN NONE N/A
Middleware Deleted tenant middleware DELETED NONE N/A
Environment Vars VITE_TENANT_ID, TENANT_ID unused ORPHANED MEDIUM Confusing
Config Files production.yml.example has unused tenant_id ORPHANED MEDIUM Confusing
Platform Tenants Service Multi-tenant service still in repo and deployable ORPHANED HIGH Resource waste
Platform Landing Service Multi-tenant landing page still in repo ORPHANED HIGH Resource waste
Core README.md References deleted files STALE LOW Confusing
Features README.md References deleted middleware STALE LOW Confusing

Recommendations by Priority

PRIORITY 1 (HIGH) - Delete Orphaned Services

These should be removed from the codebase entirely:

  1. Delete /mvp-platform-services/tenants/ directory

    • Multi-tenant signup service not needed
    • Delete entire directory: 
      rm -rf mvp-platform-services/tenants/

  2. Delete or refactor /mvp-platform-services/landing/ directory

    • Multi-tenant landing page not needed
    • Consider: If single-tenant landing is needed, refactor completely
    • If not needed: rm -rf mvp-platform-services/landing/

  3. Simplify /mvp-platform-services/ structure

    • After deletions, only vehicles/ should remain
    • Consider if /mvp-platform-services/ directory structure makes sense anymore

PRIORITY 2 (MEDIUM) - Clean up Configuration

  1. Update /config/app/production.yml.example

    • Line 4: Remove tenant_id: admin

  2. Update /.env.development

    • Line 10: Remove VITE_TENANT_ID=admin
    • Line 17: Remove TENANT_ID=admin

  3. Update /docker-compose.yml

    • Line 51: Remove VITE_TENANT_ID environment variable
    • Verify no orphaned platform service references

PRIORITY 3 (LOW) - Fix Documentation

  1. Update /backend/src/core/README.md

    • Remove line 7: - tenant.ts — Tenant configuration utilities
    • Remove line 18: - middleware/tenant.ts — Tenant extraction/validation

  2. Update /backend/src/features/documents/README.md

    • Line 24: Remove core/middleware/tenant dependency

  3. Archive redesign documentation

    • Move /docs/redesign/ to /docs/archive/redesign/ if not actively maintained

Files to Preserve (Not Affected)

These files are CLEAN and should be preserved:

  • ✅ /backend/src/** - All feature code (vehicles, documents, fuel-logs, etc.)
  • ✅ /frontend/src/** - All UI code
  • ✅ /mvp-platform-services/vehicles/** - Vehicles platform service (still needed)
  • ✅ /docker-compose.yml - Core structure is correct
  • ✅ /config/app/ - Mostly correct after line 4 removal

Verification Commands

To verify this analysis is accurate, run these commands:

# Verify no tenant_id in application code
grep -r "tenant_id" backend/src/features/ --include="*.ts" --include="*.sql" | wc -l
# Expected: 0

# Verify no tenantId in frontend
grep -r "tenantId" frontend/src/ --include="*.ts" --include="*.tsx" | wc -l
# Expected: 0

# Verify tenant middleware deleted
ls -la backend/src/core/middleware/tenant.ts 2>&1
# Expected: "No such file or directory"

# Verify tenant config deleted
ls -la backend/src/core/config/tenant.ts 2>&1
# Expected: "No such file or directory"

# Check for orphaned services
ls -la mvp-platform-services/
# Current: landing tenants vehicles
# Should be: vehicles (after cleanup)

Conclusion

The multi-tenant refactor is architecturally successful at the application level (0 tenant_id references in active code). However, orphaned platform services and stale configuration create technical debt and confusion.

Recommended action: Execute Priority 1 (delete orphaned services) and Priority 2 (clean configuration) to fully complete the refactor and prevent future confusion.

Reference in New Issue View Git Blame Copy Permalink