🏗️ Architecture: How should AI functionality be separated from gograb-space t...

Date: 2026-01-28
Time: 17:08:00 UTC
Session: editor2-73.2
Agent: angular
Confidence: 85%
Status: ✅ Documented

📋 Decision Context

Question:

How should AI functionality be separated from gograb-space to reduce bundle size while maintaining drag-drop capabilities?

Task: Session 73.1: AI App Separation Strategy - Comprehensive analysis and planning for extracting AI functionality from gograb-space into separate NX apps

🎯 Decision Made

Chosen:

Two-app architecture: app-gograb-ai (user-facing AI assistant with embeddable iframe+postMessage) + app-mcp-dashboard (admin AI dashboard). Use iframe embedding with BroadcastChannel for cross-app communication and custom drag-drop bridge protocol.

Options Considered:

1. One app (app-gograb-ai) for all AI functionality
2. Two apps (app-gograb-ai + app-mcp-dashboard)
3. Module Federation approach
4. Angular Elements (Web Components)
5. Keep AI in gograb-space with better lazy loading

💭 Reasoning

1. Two apps provide maximum bundle reduction (20%+) vs one app (15%); 2) Clear separation of user-facing vs admin concerns improves security and deployment independence; 3) Iframe+postMessage is proven pattern (existing CrossToolSyncService uses BroadcastChannel); 4) Enables long-term vision of Chrome extension and external embedding; 5) Existing embeddable-component.model.ts already has iframe support with security isolation levels.

📁 Files Involved

• apps/gograb-space/src/app/app.routes.ts
• apps/gograb-space/src/app/components/layout/main-layout/main-layout.component.ts
• libs/libs-ai/ai-panel-core/src/lib/services/ai-panel-state.service.ts
• libs/libs-foundational/core-angular/src/lib/services/cross-tool-sync.service.ts
• libs/libs-ai/gograb-ai/src/lib/ai.routes.ts

🔗 Related

• Decision ID: dev_1769620076597_azf1fl5
• Session: 73
• Workspace: editor2

Auto-generated by MCP Smart Consolidation