|
| 1 | +--- |
| 2 | +title: Architektur |
| 3 | +description: Was tatsächlich auf Ihren Systemen läuft — für die Engineers, die abwägen, ob sie dies einführen sollen. |
| 4 | +--- |
| 5 | + |
| 6 | +# Architektur |
| 7 | + |
| 8 | +Eine praxisnahe Sicht darauf, was auf Ihren Maschinen läuft, wenn Sie |
| 9 | +ObjectOS bereitstellen, welche Daten Ihr Netzwerk verlassen und welche nicht. |
| 10 | + |
| 11 | +Das mentale Modell besteht aus zwei dünnen Schichten: |
| 12 | + |
| 13 | +1. **Metadaten** — Pakete aus Objekten / Views / Actions / Flows / |
| 14 | + Agents. Größtenteils vom [AI Builder](/docs/build/ai-builder) |
| 15 | + gegen eine sandboxed Tool-API geschrieben; teils von Hand bearbeitet, stets |
| 16 | + versionskontrolliert und auditiert. |
| 17 | +2. **Eine einzige Node.js-Laufzeit**, die diese Metadaten in eine |
| 18 | + funktionierende Anwendung interpretiert — REST-API, Console-UI, Berechtigungen, Jobs, AI-Tools — alles in einem Prozess, der mit Ihrer Datenbank kommuniziert. |
| 19 | + |
| 20 | +Kein Codegenerierungsschritt, keine Deploy-Pipeline zwischen „Benutzer hat |
| 21 | +beschrieben, was er möchte" und „es ist live". Die Laufzeit lädt die neuen |
| 22 | +Metadaten nach einer HITL-Freigabe per Hot-Reload. |
| 23 | + |
| 24 | +## Was Sie bereitstellen |
| 25 | + |
| 26 | +Ein Node.js-Prozess pro ObjectOS-Instanz. Das ist alles. |
| 27 | + |
| 28 | +```text |
| 29 | +┌─────────────────────────────────────────────────────┐ |
| 30 | +│ ObjectOS process │ |
| 31 | +│ ┌───────────────────────────────────────────────┐ │ |
| 32 | +│ │ HTTP dispatcher (/ · /api · /_console …) │ │ |
| 33 | +│ ├───────────────────────────────────────────────┤ │ |
| 34 | +│ │ Per-project ObjectKernel (LRU cached) │ │ |
| 35 | +│ │ ├─ Auth (Better Auth) │ │ |
| 36 | +│ │ ├─ Security (RBAC + row-level + field) │ │ |
| 37 | +│ │ ├─ ObjectQL (data engine, generates SQL) │ │ |
| 38 | +│ │ ├─ REST API generator │ │ |
| 39 | +│ │ └─ Capabilities loaded per artifact │ │ |
| 40 | +│ │ (audit, storage, jobs, queue, AI …) │ │ |
| 41 | +│ └───────────────────────────────────────────────┘ │ |
| 42 | +└──────────┬──────────────────────────────────────────┘ |
| 43 | + │ |
| 44 | + ▼ |
| 45 | + Your business database |
| 46 | + (Postgres / MySQL / SQLite / Turso / MongoDB) |
| 47 | +``` |
| 48 | + |
| 49 | +Es hat die Komplexität einer einzigen statisch gelinkten Binärdatei. Kein |
| 50 | +Sidecar, kein Kafka, keine separate Cache-Schicht erforderlich. Fügen Sie diese hinzu, wenn Sie |
| 51 | +sie brauchen; zahlen Sie nicht am ersten Tag dafür. |
| 52 | + |
| 53 | +## Wo Ihre Daten liegen |
| 54 | + |
| 55 | +| Daten | Liegen in | Verlassen Ihr Netzwerk? | |
| 56 | +|---|---|---| |
| 57 | +| Geschäftsdatensätze | Ihrer Datenbank | **Nein** | |
| 58 | +| Benutzerkonten, Sitzungen, OAuth-Tokens | Ihrer Datenbank | **Nein** | |
| 59 | +| Audit-Log | Ihrer Datenbank | **Nein** | |
| 60 | +| Einstellungen, API-Schlüssel, Secrets | Ihrer Datenbank / Secret-Manager | **Nein** | |
| 61 | +| Hochgeladene Dateien | Ihrer Festplatte oder Ihrem S3/R2-Bucket | **Nein** | |
| 62 | +| Die kompilierte App-Definition (`objectstack.json`) | Einer Datei auf der Festplatte oder abgerufen von Ihrer Control Plane | Optional | |
| 63 | + |
| 64 | +ObjectOS telefoniert nicht nach Hause. Keine Telemetrie. Keine Lizenzprüfung. Wenn Sie den |
| 65 | +Internetzugang vollständig kappen, läuft es unbegrenzt weiter. Siehe |
| 66 | +[Air-gapped](/docs/deploy/air-gapped). |
| 67 | + |
| 68 | +## Wie eine Anfrage bedient wird |
| 69 | + |
| 70 | +```text |
| 71 | +1. Ingress / TLS termination (your load balancer) |
| 72 | +2. HTTP dispatcher (security headers, request id) |
| 73 | +3. Hostname → project resolution (cached, TTL configurable) |
| 74 | +4. Get or build per-project kernel from LRU |
| 75 | +5. AuthPlugin — session cookie, bearer token, or API key |
| 76 | +6. SecurityPlugin — RBAC + row-level + field-level checks |
| 77 | +7. Route handler — generated REST, declarative action, or custom |
| 78 | +8. Data driver — ObjectQL compiles to SQL / Mongo query |
| 79 | +9. Response with X-Request-Id propagated |
| 80 | +``` |
| 81 | + |
| 82 | +Die Schritte 4–8 werden typischerweise in < 5 ms ausgeführt, sobald der Kernel warm ist. |
| 83 | + |
| 84 | +## Die drei Schichten (nur relevant, wenn Sie integrieren) |
| 85 | + |
| 86 | +Die meisten Kunden stellen nur **ObjectOS** bereit. Die anderen beiden Schichten existieren, falls |
| 87 | +Sie wissen möchten, woher das Artefakt stammt: |
| 88 | + |
| 89 | +| Schicht | Was es ist | Wo es läuft | |
| 90 | +|---|---|---| |
| 91 | +| **Framework** (`@objectstack/*`) | Open-Source-Kernel, ObjectQL, Plugins, Treiber | npm — zur Build-Zeit eingebunden | |
| 92 | +| **Control Plane** (optional) | Veröffentlicht kompilierte `objectstack.json`-Artefakte; Sie können die gehostete ObjectStack Cloud nutzen, eine eigene betreiben oder sie ganz weglassen | Ihre CI, unsere Cloud oder Ihr Laptop | |
| 93 | +| **ObjectOS** | Die Laufzeit, die Sie betreiben | **Ihre Infrastruktur** | |
| 94 | + |
| 95 | +Wenn Sie eine einzelne App ausliefern, benötigen Sie keine Control Plane — |
| 96 | +kompilieren Sie `objectstack.config.ts → dist/objectstack.json` in Ihrer CI und |
| 97 | +liefern Sie das JSON im Image aus. Wenn Sie einen internen App-Marketplace |
| 98 | +mit vielen Tenants und Apps betreiben, ist die Control Plane der Ort, an dem der |
| 99 | +Katalog liegt. |
| 100 | + |
| 101 | +## Boot-Modi |
| 102 | + |
| 103 | +| Modus | Wann | Wie | |
| 104 | +|---|---|---| |
| 105 | +| **Standalone** | Einzelne App, Entwicklung, Evaluierung, Air-gapped, die meisten Produktionsbereitstellungen | `pnpm dev` oder `dist/objectstack.json` von der Festplatte ausführen | |
| 106 | +| **File-backed** | Produktion mit extern verwalteten Artefakten | `OS_ARTIFACT_PATH=/path/to/objectstack.json` setzen | |
| 107 | +| **Cloud-connected** | Multi-Tenant- / Multi-App-Bereitstellungen, gespeist von einer Control Plane | `OS_CLOUD_URL` + `OS_CLOUD_API_KEY` setzen | |
| 108 | + |
| 109 | +Der Modus wird automatisch anhand von Umgebungsvariablen erkannt. |
| 110 | + |
| 111 | +## Performance-Eigenschaften |
| 112 | + |
| 113 | +| Metrik | Wert | |
| 114 | +|---|---| |
| 115 | +| Kaltstart (Prozess hochgefahren, bereit für Traffic) | ~1 Sekunde | |
| 116 | +| Kernel-Warmup (erste Anfrage an ein Projekt) | 50–300 ms je nach Capabilities | |
| 117 | +| Latenz bei warmer Anfrage (CRUD via REST) | typischerweise < 10 ms + Datenbanklatenz | |
| 118 | +| Speicherbedarf | ~150 MB Basis; ~10–30 MB pro aktivem Projekt-Kernel | |
| 119 | +| Gleichzeitige Projekte pro Instanz | Begrenzt durch `OS_KERNEL_CACHE_SIZE` (Standard 32) | |
| 120 | + |
| 121 | +## Warum diese Form |
| 122 | + |
| 123 | +- **Ein Node-Prozess, keine Sidecars** → passt in ein `docker run`, passt in eine |
| 124 | + systemd-Unit, passt in eine Lambda-ähnliche Umgebung. |
| 125 | +- **Per-Projekt-Kernel, LRU-gecacht** → eine Instanz kann viele |
| 126 | + kleine Apps bedienen, ohne bei jeder Anfrage die Warmup-Kosten zu tragen. |
| 127 | +- **Generierte APIs auf Basis deklarierter Metadaten** → es gibt keinen Codegen- |
| 128 | + Schritt in Ihrer CI, kein Client-SDK zum Veröffentlichen; die API entspricht Ihrem Datenmodell konstruktionsbedingt. |
| 129 | +- **Alle Capabilities sind optionale Plugins** → die Image-Größe skaliert mit dem, |
| 130 | + was Sie tatsächlich nutzen. |
| 131 | + |
| 132 | +## Wie es weitergeht |
| 133 | + |
| 134 | +- [Production Readiness](/docs/operate/production) — Checkliste, bevor |
| 135 | + Sie es echtem Traffic aussetzen. |
| 136 | +- [Runtime Configuration](/docs/configure/runtime) — Verdrahtung von Datenbanken, |
| 137 | + Caches und Secrets. |
| 138 | +- [Runtime Capabilities](/docs/reference/runtime-capabilities) — |
| 139 | + welche optionalen Pakete existieren und was sie ermöglichen. |
0 commit comments