Skip to content
AnglinAI Docs

Admin Dashboard Architecture Recommendation

Date: February 15, 2026 Status: Pending - To be addressed after core project functionality is complete

Current State

Health Endpoint

  • URL: /health
  • Returns: { status: "healthy", timestamp: "..." }
  • Basic health check - confirms API is running

Existing Admin System (Project-Specific)

Backend API (/api/admin/*):

  • /stats - Dashboard stats (users, charts, extractions)
  • /users - List all users with credit balances
  • /credits/grant - Grant credits to users
  • /credits/refund - Refund credits

Frontend:

  • /admin - Main admin dashboard page
  • /admin/docs - Admin documentation
  • Admin link in header (only visible to admin users)

Currently Missing:

  • Model quality metrics viewing
  • Extraction history analysis
  • Health monitoring across services
  • Cross-project insights

The Decision: Unified vs Project-Specific

Since the database serves 3 projects (org-chart, tagdai, and one other), we need to decide on admin architecture.

Build once, manage everything

Structure

admin.anglin.com/
├── /dashboard              # Overall stats across all projects
├── /projects
│   ├── /org-chart         # Org chart specific metrics
│   │   ├── /extractions   # Vision AI quality metrics
│   │   ├── /users         # Org chart users
│   │   └── /credits       # Credit management
│   ├── /tagdai            # TagdAI specific metrics
│   └── /project3          # Third project
├── /users                 # All users across projects
├── /database              # Shared database health & metrics
├── /health                # All API health statuses
└── /analytics             # Cross-project analytics

Advantages

✅ Single dashboard for all projects ✅ View metrics across all products ✅ Centralized user management ✅ Better database insights (since it’s shared) ✅ One place to monitor health of all APIs ✅ Avoid duplicate code across projects ✅ Cross-project analytics and reporting ✅ Easier to maintain (one codebase)

Disadvantages

❌ More complex initial setup ❌ Requires coordination across teams ❌ Needs authentication/authorization for all projects

Technology Stack

  • Framework: Next.js (same as org-chart app)
  • Styling: Tailwind CSS (consistent with projects)
  • Auth: Supabase (shared auth across projects)
  • Deployment: Vercel or Cloudflare Pages
  • Domain: admin.anglin.com

Features to Include

Dashboard Home

  • Total users across all projects
  • Total API calls / requests
  • Revenue/credits across all projects
  • Health status of all APIs
  • Recent activity feed

Project-Specific Pages

Each project gets its own section with:

  • Project-specific metrics
  • User management
  • API health monitoring
  • Error logs
  • Performance metrics

Org Chart Specific

  • Quality Metrics Viewer: View extraction quality metrics from the new table
    • Model performance comparison (Gemini vs Claude)
    • Success rates over time
    • Quality score trends
    • Suspicious name detection stats
  • Extraction history per chart
  • Credit usage analytics
  • Template usage statistics

Database Management

  • Connection pool status
  • Query performance
  • Migration history
  • Shared tables overview

User Management

  • View all users across projects
  • Grant/revoke admin access
  • View user activity across projects
  • Manage credits globally

Option 2: Project-Specific Admin (Current Setup)

Keep separate admin dashboards per project

Advantages

✅ Simpler - already mostly built ✅ Each team manages their own project ✅ Clearer separation of concerns ✅ Faster to implement enhancements

Disadvantages

❌ Duplicate code across projects ❌ Hard to see cross-project insights ❌ Can’t easily manage shared database ❌ Multiple places to check health ❌ More maintenance burden

Enhancements Needed

If staying project-specific, add to current /admin:

  • Quality metrics viewing (new extraction_quality_metrics table)
  • Model performance comparison charts
  • Enhanced health monitoring
  • API status indicators
  • Error tracking

Final Recommendation

Build a unified admin site for the following reasons:

  1. Shared Database: All projects share one database → centralized management makes sense
  2. Cross-Project Analytics: Ability to see insights across all products
  3. Quality Metrics: New extraction quality metrics can be part of a larger analytics suite
  4. Health Monitoring: Monitor all 3 API endpoints from one dashboard
  5. Same Admin Users: Likely the same people administering all projects
  6. Scalability: Easier to add future projects
  7. Cost Effective: One admin site vs maintaining 3 separate admin sections

Implementation Plan (Future)

Phase 1: Foundation

  1. Create new Next.js app for admin site
  2. Set up authentication with Supabase
  3. Create base layout and navigation
  4. Implement role-based access control

Phase 2: Core Features

  1. Dashboard home with aggregate stats
  2. Health monitoring for all APIs
  3. User management across projects
  4. Database connection monitoring

Phase 3: Project-Specific Features

  1. Migrate org-chart admin features
  2. Add quality metrics viewing
  3. Add extraction history analysis
  4. Create project-specific sections for other projects

Phase 4: Analytics & Insights

  1. Cross-project analytics
  2. Revenue/credit tracking
  3. Usage trends and reports
  4. Automated alerts for issues

Current Action Items

For now, stay with project-specific admin and enhance it:

  1. ✅ Quality metrics table created
  2. ✅ Quality metrics stored on each extraction
  3. ⏳ Add quality metrics viewing page to /admin
  4. ⏳ Add model comparison charts
  5. ⏳ Enhance health endpoint to include more details

Revisit unified admin decision after core org-chart functionality is complete.

Questions to Answer Before Building Unified Admin

  1. Who are the admin users? (Same across all projects?)
  2. What permissions model? (Global admin vs project-specific admin?)
  3. Which project should be migrated first?
  4. What’s the timeline/priority?
  5. Who will maintain it?
  6. Budget for development?
  • /workers/api/src/routes/admin.ts - Current admin API routes
  • /apps/web/src/app/admin/page.tsx - Current admin dashboard
  • /supabase/migrations/004_extraction_quality_metrics.sql - Quality metrics table
  • /workers/api/src/services/extraction-validator.ts - Quality metrics calculator

Notes

  • The shared database already serves 3 projects, so migration history management will be needed regardless of choice
  • Consider monitoring costs across all projects from unified dashboard
  • Could add Stripe revenue tracking if needed
  • Health endpoints should be enhanced to include database connection status, API response times, etc.