# 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).