karim
ca859c4aa4
Standalone-Browser-Port von DOSSIER. Enthaelt das semantische Modell mit Plan-/3D-Ableitung, Zeichen- und Editierwerkzeuge, Rhino-artiges Befehlssystem, dockbares Panel-System, Resource-Manager, DXF/.lin/.pat-Import, i18n (de/en) sowie Projektdokumentation und Probe-Harness.
44 lines
2.2 KiB
Markdown
44 lines
2.2 KiB
Markdown
# Backend & Kollaboration — Architekturentscheidung
|
||
|
||
> Stand: 2026-06-29 · Ziel: komplett self-hosted, kollaborations-offen
|
||
|
||
## Grundsatz
|
||
So lange wie möglich **client-only** bleiben; das Backend additiv einführen, ohne
|
||
den Kern umzubauen. Die Pure-Ableitungs-Architektur (ein serialisierbares Modell,
|
||
alle Sichten abgeleitet) ist bereits kollaborations-freundlich.
|
||
|
||
## Phasen
|
||
| Phase | Persistenz / Backend |
|
||
|---|---|
|
||
| **0–3** (Modellierer) | **Client-only**: IndexedDB + Datei-Export/Import (JSON). Offline-fähig (PWA möglich). Kein Server. |
|
||
| **5** (Konten/Persistenz) | **Supabase self-hosted** (Docker Compose): Postgres + Auth + Storage. Projekte, Versionen, Dateien (IFC/Pläne/Assets). Row-Level-Security pro Nutzer/Projekt. |
|
||
| **6** (Kollaboration) | **Yjs (CRDT)** + **Hocuspocus** Sync-Server (Container), persistiert Snapshots nach Postgres. Presence/Cursors. Optional Supabase-Realtime nur für leichte Broadcasts. |
|
||
|
||
## Warum Yjs/Hocuspocus statt reinem Supabase-Realtime
|
||
Gleichzeitiges Editieren eines strukturierten Dokuments braucht Konfliktauflösung
|
||
(CRDT). Yjs ist dafür Standard; Hocuspocus ist der self-hostbare Server dazu und
|
||
kann nach Postgres (Supabase) persistieren. Supabase-Realtime allein wäre nur
|
||
Pub/Sub ohne Merge-Semantik.
|
||
|
||
## Was wir JETZT schon richtig machen (damit Collab nicht blockiert)
|
||
- Dokumentmodell rein **JSON-serialisierbar**, keine Zyklen, stabile IDs.
|
||
- Edits immutable über `setProject` → später leicht auf Yjs-Doc abbildbar
|
||
(`Y.Map`/`Y.Array` je Sammlung: drawingLevels, layers, components, walls …).
|
||
- Kein Wahrheits-Zustand im Three.js-Scene-Graph oder im DOM — alles ableitbar.
|
||
- Ressourcen (Components/Hatches/Lines) als referenzierte Bibliotheken (IDs) →
|
||
gut mergebar.
|
||
|
||
## Self-hosted Stack (Skizze, Phase 5/6)
|
||
```
|
||
docker-compose:
|
||
supabase (postgres, gotrue auth, storage, kong gateway, studio)
|
||
hocuspocus (yjs websocket sync, persist -> postgres)
|
||
web (vite build, statisch via nginx/caddy)
|
||
```
|
||
Alles auf eigener Infrastruktur lauffähig; keine externe Cloud nötig.
|
||
|
||
## Offene Punkte
|
||
- Granularität der CRDT-Struktur (pro Sammlung vs. pro Element).
|
||
- Datei-Storage (Supabase Storage vs. S3-kompatibel/MinIO im selben Stack).
|
||
- Auth-Modell (E-Mail, OIDC/SSO fürs Büro).
|