Architektur

Eine praxisnahe Sicht darauf, was auf Ihren Maschinen läuft, wenn Sie ObjectOS bereitstellen, welche Daten Ihr Netzwerk verlassen und welche nicht.

Das mentale Modell besteht aus zwei dünnen Schichten:

1. Metadaten — Pakete aus Objekten / Views / Actions / Flows / Agents. Größtenteils vom AI Builder gegen eine sandboxed Tool-API geschrieben; teils von Hand bearbeitet, stets versionskontrolliert und auditiert.
2. Eine einzige Node.js-Laufzeit, die diese Metadaten in eine funktionierende Anwendung interpretiert — REST-API, Console-UI, Berechtigungen, Jobs, AI-Tools — alles in einem Prozess, der mit Ihrer Datenbank kommuniziert.

Kein Codegenerierungsschritt, keine Deploy-Pipeline zwischen „Benutzer hat beschrieben, was er möchte" und „es ist live". Die Laufzeit lädt die neuen Metadaten nach einer HITL-Freigabe per Hot-Reload.

Was Sie bereitstellen

Ein Node.js-Prozess pro ObjectOS-Instanz. Das ist alles.

┌─────────────────────────────────────────────────────┐
│                  ObjectOS process                   │
│  ┌───────────────────────────────────────────────┐  │
│  │   HTTP dispatcher  (/ · /api · /_console …)    │  │
│  ├───────────────────────────────────────────────┤  │
│  │   Per-project ObjectKernel (LRU cached)       │  │
│  │   ├─ Auth (Better Auth)                       │  │
│  │   ├─ Security (RBAC + row-level + field)      │  │
│  │   ├─ ObjectQL (data engine, generates SQL)    │  │
│  │   ├─ REST API generator                       │  │
│  │   └─ Capabilities loaded per artifact         │  │
│  │      (audit, storage, jobs, queue, AI …)      │  │
│  └───────────────────────────────────────────────┘  │
└──────────┬──────────────────────────────────────────┘
           │
           ▼
   Your business database
   (Postgres / MySQL / SQLite / Turso / MongoDB)

Es hat die Komplexität einer einzigen statisch gelinkten Binärdatei. Kein Sidecar, kein Kafka, keine separate Cache-Schicht erforderlich. Fügen Sie diese hinzu, wenn Sie sie brauchen; zahlen Sie nicht am ersten Tag dafür.

Wo Ihre Daten liegen

ObjectOS telefoniert nicht nach Hause. Keine Telemetrie. Keine Lizenzprüfung. Wenn Sie den Internetzugang vollständig kappen, läuft es unbegrenzt weiter. Siehe Air-gapped.

Wie eine Anfrage bedient wird

1. Ingress / TLS termination     (your load balancer)
2. HTTP dispatcher               (security headers, request id)
3. Hostname → project resolution (cached, TTL configurable)
4. Get or build per-project kernel from LRU
5. AuthPlugin    — session cookie, bearer token, or API key
6. SecurityPlugin — RBAC + row-level + field-level checks
7. Route handler — generated REST, declarative action, or custom
8. Data driver   — ObjectQL compiles to SQL / Mongo query
9. Response with X-Request-Id propagated

Die Schritte 4–8 werden typischerweise in < 5 ms ausgeführt, sobald der Kernel warm ist.

Die drei Schichten (nur relevant, wenn Sie integrieren)

Die meisten Kunden stellen nur ObjectOS bereit. Die anderen beiden Schichten existieren, falls Sie wissen möchten, woher das Artefakt stammt:

Wenn Sie eine einzelne App ausliefern, benötigen Sie keine Control Plane — kompilieren Sie objectstack.config.ts → dist/objectstack.json in Ihrer CI und liefern Sie das JSON im Image aus. Wenn Sie einen internen App-Marketplace mit vielen Tenants und Apps betreiben, ist die Control Plane der Ort, an dem der Katalog liegt.

Boot-Modi

Der Modus wird automatisch anhand von Umgebungsvariablen erkannt.

Performance-Eigenschaften

Warum diese Form

• Ein Node-Prozess, keine Sidecars → passt in ein docker run, passt in eine systemd-Unit, passt in eine Lambda-ähnliche Umgebung.
• Per-Projekt-Kernel, LRU-gecacht → eine Instanz kann viele kleine Apps bedienen, ohne bei jeder Anfrage die Warmup-Kosten zu tragen.
• Generierte APIs auf Basis deklarierter Metadaten → es gibt keinen Codegen- Schritt in Ihrer CI, kein Client-SDK zum Veröffentlichen; die API entspricht Ihrem Datenmodell konstruktionsbedingt.
• Alle Capabilities sind optionale Plugins → die Image-Größe skaliert mit dem, was Sie tatsächlich nutzen.

Wie es weitergeht

• Production Readiness — Checkliste, bevor Sie es echtem Traffic aussetzen.
• Runtime Configuration — Verdrahtung von Datenbanken, Caches und Secrets.
• Runtime Capabilities — welche optionalen Pakete existieren und was sie ermöglichen.