Architektur
Cuby ist als Single-Binary konzipiert, die einen HTTP-Server mit Web-Oberfläche bereitstellt und die Verwaltung aller ProcessCube®-Komponenten übernimmt. Die Architektur besteht aus dem Cuby Core, Plugin-Workern und den verwalteten Produkten.
Gesamtarchitektur
Komponenten
| Komponente | Aufgabe |
|---|---|
| HTTP Server | Bun-nativer HTTP-Server auf Port 3847, dient die REST API und das Frontend aus |
| ProductManager | Spawnt und überwacht Produkt-Prozesse, Auto-Restart bei Crash nach 5 Sekunden |
| PluginLoader | Verwaltet langlebige Worker-Prozesse, leitet HTTP-Requests und Socket.IO-Events weiter |
| Installer | npm-Pakete vom Marketplace installieren, Plugin-Deploy/Update/Uninstall orchestrieren |
| Marketplace Client | Produktkatalog, Kurse und Videos vom Marketplace abrufen |
| Config Service | Zentrale Konfigurationsverwaltung (~/.processcube/config.json) |
| Secret Store | API Keys und Plugin-Secrets sicher speichern (Bun.secrets lokal, K8s Secrets im Operator-Modus) |
| ProcessCube Registry | In-Memory-Registry aller Engine/LowCode/Authority-Instanzen |
| ProcessCube Connector | Socket.IO-Verbindung zu LowCode für Konfigurations-Sync |
| Port Manager | Port-Reservation für Plugins, Kollisionsvermeidung |
| Sub-Cuby Registry | Verbindet mehrere Cuby-Instanzen, teilt ProcessCubes |
| Cuby Context API | Stellt Plugins eine einheitliche API bereit (Ports, Secrets, Deploy, ProcessCubes) |
| Auth Middleware | Authentifizierung via API Key, Session Cookie oder PostMessage Token |
Technologie-Stack
| Schicht | Technologie |
|---|---|
| Runtime | Bun (Cross-Platform Compilation zu Single-Binary) |
| Backend | Bun HTTP Server (native) mit Socket.IO (@socket.io/bun-engine) |
| Frontend | React 18 + Vite + React Router v7 (JavaScript) |
| Styling | Tailwind CSS |
| Echtzeit | Socket.IO |
| Config | ~/.processcube/config.json + Secret Store |
| Node.js | v22 via fnm (für Plugin-Worker) |
| Kubernetes | @kubernetes/client-node (Operator-Modus) |
| Engine Client | @5minds/processcube_engine_client (BPMN-Deployment) |
Zwei Betriebsmodi
Cuby kann in zwei Modi betrieben werden:
| Aspekt | Lokaler Modus | Kubernetes Operator |
|---|---|---|
| Produkte | Child-Prozesse | Deployments/Services |
| Konfiguration | ~/.processcube/config.json | ConfigMaps + Secrets |
| API Key | Bun.secrets | K8s Secret |
| Logs | Datei + In-Memory | Pod Logs |
| Skalierung | Einzelner Prozess | Replicas, Rolling Restart |
Details zum Kubernetes-Betrieb unter Kubernetes Operator.
Worker-Architektur
Plugin-Lifecycle-Methoden (deploy, start, stop, undeploy) laufen in separaten
Node.js-Child-Prozessen — nicht im Bun-Hauptprozess:
- Grund: Die kompilierte Bun-Binary löst transitive Dependencies bei dynamischem
import()nicht korrekt auf - Kommunikation: JSON-Lines-Protokoll über stdin/stdout
- RPC: Cuby-Methoden-Aufrufe werden vom Worker über das Protokoll an den Main-Thread weitergeleitet
Nur init() (Route-Registrierung) läuft auf dem Main-Thread im PluginLoader.
Details zum Plugin-System unter Plugin-System.
Datenfluss
- Frontend → Backend: REST API Calls und Socket.IO Events über Port 3847
- Backend → Marketplace: npm-Registry und Produkt-API über HTTPS
- Backend → Produkte: Prozess-Spawning (lokal) oder K8s API (Operator-Modus)
- Backend → Plugin-Worker: JSON-Lines RPC über stdin/stdout
- Backend ↔ LowCode: Socket.IO-Verbindung für Konfigurations-Sync
- Backend ↔ Sub-Cubies: REST + Socket.IO für ProcessCube®-Federation
Weiterführend
- Plattform-Produkte — Welche Produkte Cuby verwaltet
- Plugin-System — Plugin-Architektur im Detail
- App SDK — SDK für die Entwicklung von ProcessCube®-Anwendungen