04 Tech Stack Mapping
UDIP – Feature → Tech Stack Mapping
This document provides a comprehensive mapping of each platform feature to its required capabilities, recommended technologies, and technical justifications.
Technology Decision Framework
Core Backend: Node.js Orchestration
Decision: Use Node.js as the primary orchestration and backend layer.
Rationale:
- Event-driven architecture: Node.js excels at handling concurrent, I/O-intensive operations (process supervision, WebSocket connections, log streaming)
- Non-blocking I/O: Critical for managing multiple long-running processes without blocking
- Process management: Native
child_process and node-pty libraries provide robust PTY support for terminal emulation and process supervision
- Real-time capabilities: Built-in support for WebSocket servers (Socket.io, ws) enables live dashboard updates
- Cross-platform consistency: Works identically on Windows, macOS, and Linux
- Mature ecosystem: Rich libraries for system operations, logging, monitoring, and automation
- Performance: Single-threaded event loop handles thousands of concurrent connections efficiently
Why NOT Python for orchestration:
- Python's Global Interpreter Lock (GIL) limits true parallelism
- Python is not optimized for long-running, concurrent I/O operations
- Process supervision and PTY handling are more mature in Node.js
- Python's async ecosystem (asyncio) is less mature than Node.js for this use case
- Python is better suited for compute-intensive AI tasks, not I/O orchestration
AI Subsystem: Python/FastAPI
Decision: Use Python with FastAPI exclusively for AI intelligence services.
Rationale:
- LLM ecosystem: All major LLM SDKs (OpenAI, Anthropic, Cohere) are Python-first
- AI frameworks: LangChain, LlamaIndex, Transformers are Python-native
- Vector databases: Best support for Chroma, Qdrant, Pinecone in Python
- FastAPI performance: Async-capable, type-safe, and fast enough for AI inference
- Isolation: Running AI as a separate service prevents blocking the orchestration core
- Language fit: Python is the best language for AI/ML workloads
Why Python is NOT used for orchestration:
- Orchestration requires lightweight, concurrent event handling—Node.js is superior
- Python's strength is in compute-intensive AI tasks, not I/O-heavy system operations
Frontend: React + Vite
Decision: Use React with TypeScript, built with Vite.
Rationale:
- Component ecosystem: Rich UI component libraries (Ant Design, Material-UI, Shadcn)
- TypeScript support: Type safety for large-scale applications
- Real-time UI: Easy integration with WebSocket libraries
- Vite performance: Fast HMR (Hot Module Replacement) and optimized production builds
- Ecosystem maturity: React has the best support for terminal emulation (xterm.js), code editors (Monaco), and file trees
- Developer experience: Familiar to most frontend developers
Alternatives considered:
- Vue.js: Smaller ecosystem for specialized components (terminal, code editor)
- Svelte: Less mature ecosystem, fewer UI libraries
- Angular: Too heavyweight for this use case
Feature-by-Feature Technology Mapping
1. Unified Dashboard
| Required Capabilities |
Technology |
Justification |
| Real-time data updates |
WebSocket (Socket.io) |
Bi-directional, event-driven, low latency |
| Responsive UI components |
React + Tailwind CSS |
Fast development, modern aesthetics |
| State management |
Zustand or Redux Toolkit |
Predictable state for complex dashboards |
| Data visualization |
Chart.js or Recharts |
Lightweight, customizable charts |
2. Project Launcher & Service Manager
| Required Capabilities |
Technology |
Justification |
| Process spawning & supervision |
Node.js child_process |
Native, cross-platform, robust |
| Auto-restart on failure |
Custom supervisor logic |
PM2-like behavior, configurable policies |
| Process state persistence |
SQLite or LevelDB |
Lightweight, embedded, no external dependencies |
| Inter-process communication |
Event Emitter or Redis |
In-memory or distributed messaging |
3. Integrated Terminal & Command Runner
| Required Capabilities |
Technology |
Justification |
| PTY (Pseudo-TTY) support |
node-pty |
Full terminal emulation, native Node.js library |
| Terminal UI rendering |
xterm.js |
Industry-standard web terminal, supports full TTY |
| WebSocket backend |
ws or Socket.io |
Low-latency terminal streaming |
| Session persistence |
Redis or in-memory store |
Reconnect to existing terminal sessions |
4. File Explorer & Code Editor
| Required Capabilities |
Technology |
Justification |
| File tree rendering |
React component (custom or library) |
Hierarchical tree view with lazy loading |
| Code editing |
Monaco Editor or CodeMirror |
Monaco = VS Code's editor, CodeMirror = lightweight |
| Syntax highlighting |
Built into Monaco/CodeMirror |
Language-aware highlighting |
| File system operations |
Node.js fs module |
Native file read/write |
| Watch for file changes |
chokidar |
Efficient file watching, cross-platform |
5. Monitoring & Logs
| Required Capabilities |
Technology |
Justification |
| Log collection |
Streams from process stdout/stderr |
Native Node.js streams |
| Log indexing |
SQLite FTS or Elasticsearch |
SQLite = simple, Elasticsearch = advanced search |
| Metrics collection |
Custom Node.js collectors |
CPU, memory, disk usage via OS APIs |
| Real-time log streaming |
WebSocket |
Live log tailing in browser |
| Alerting engine |
Custom event-driven logic |
Event bus + rule evaluation |
6. Deployment Panel
| Required Capabilities |
Technology |
Justification |
| Workflow orchestration |
Custom state machine |
Config-driven, YAML/JSON definitions |
| Script execution |
Node.js child_process |
Run shell scripts, Docker commands, etc. |
| Deployment history |
SQLite |
Persistent, queryable history |
| Rollback logic |
Git tags or snapshots |
Version control or file system snapshots |
7. Alerting & Automation
| Required Capabilities |
Technology |
Justification |
| Event monitoring |
Event Bus (EventEmitter or Redis) |
Centralized event distribution |
| Rule engine |
Custom JS evaluator or JSON Logic |
Config-driven condition evaluation |
| Notification delivery |
Nodemailer, Slack SDK, webhooks |
Multi-channel alerting |
| Automated actions |
API calls to orchestration core |
Execute commands, restart services |
8. Multi-Server Support
| Required Capabilities |
Technology |
Justification |
| Remote server communication |
SSH (ssh2 npm package) |
Secure, standard protocol |
| Lightweight agents (optional) |
Custom Node.js agents |
Deployed on remote servers, relay data |
| Centralized control plane |
Main UDIP server |
Aggregates data from all servers |
9. Plugin System
| Required Capabilities |
Technology |
Justification |
| Plugin loading |
Dynamic require() or ESM imports |
Load plugins at runtime |
| Sandboxing |
VM2 or Node.js Worker Threads |
Isolated execution environments |
| Plugin registry |
Local file system + manifest files |
Simple, no external dependencies |
| API hooks |
Event listeners + middleware |
Plugins subscribe to platform events |
10. AI Development Assistant
| Required Capabilities |
Technology |
Justification |
| LLM interface |
OpenAI SDK, LangChain, Anthropic SDK |
Industry-standard AI libraries |
| Context management |
Vector DB (Chroma, Qdrant) |
Semantic search over project files |
| Code analysis |
AST parsers (Babel, tree-sitter) |
Understand code structure |
| Action execution |
Internal APIs to orchestration core |
Edit files, run commands, restart services |
| Streaming responses |
FastAPI + Server-Sent Events (SSE) |
Real-time AI response streaming |
Database & Storage Strategy
| Data Type |
Technology |
Justification |
| Process state, configs |
SQLite |
Embedded, no setup, ACID-compliant |
| Logs (basic) |
SQLite FTS |
Full-text search, no external dependencies |
| Logs (advanced) |
Elasticsearch |
Scalable, advanced querying |
| Vector embeddings |
ChromaDB or Qdrant |
AI context awareness, semantic search |
| Session data |
Redis (optional) |
Distributed sessions, caching |
Communication & Networking
| Use Case |
Technology |
Justification |
| Frontend ↔ Backend (real-time) |
WebSocket (Socket.io) |
Bi-directional, low-latency |
| Frontend ↔ Backend (REST) |
Express.js or Fastify |
Standard HTTP APIs |
| Backend ↔ AI Subsystem |
HTTP/REST |
Decoupled services |
| Internal service communication |
Event Bus (EventEmitter or Redis) |
Pub-sub pattern, decoupled |
Why NOT Other Frameworks?
Why NOT Django or Flask (Python) for Backend?
- Not event-driven: Django/Flask are request-response frameworks, not designed for long-running processes
- GIL limitations: Python's GIL prevents true parallelism, problematic for concurrent operations
- Process management: Python lacks mature PTY and process supervision libraries
- Real-time performance: Node.js outperforms Python for WebSocket-heavy applications
Why NOT Go for Backend?
- Ecosystem maturity: Node.js has better libraries for terminal emulation, logging, and system monitoring
- Developer familiarity: JavaScript is more accessible than Go for most developers
- Frontend synergy: Shared language (JavaScript/TypeScript) between frontend and backend
Why NOT Rust for Backend?
- Complexity: Rust's learning curve is steep; Node.js is more accessible
- Ecosystem: Node.js has a richer ecosystem for this use case
- Development speed: Node.js enables faster prototyping and iteration
Technology Summary Table
| Layer |
Technology |
Rationale |
| Orchestration Core |
Node.js |
Event-driven, process management, real-time communication |
| AI Subsystem |
Python/FastAPI |
LLM ecosystem, AI frameworks, vector databases |
| Frontend |
React + Vite |
Component ecosystem, TypeScript support, developer experience |
| Database |
SQLite (default), Elasticsearch (advanced) |
Embedded, no external dependencies, scalable when needed |
| Real-time Communication |
WebSocket (Socket.io) |
Low-latency, bi-directional |
| Terminal Emulation |
xterm.js + node-pty |
Industry-standard, full TTY support |
| Code Editor |
Monaco Editor |
VS Code's editor, feature-rich |
Document Version: 1.0
Last Updated: January 2026