ZeasyAlexandClaude Opus 5
d07c18441b
Zugangsdaten kommen jetzt aus der App statt aus einer .env: ein Einrichtungs-Assistent auf http://localhost:4792/setup nimmt Client-ID, Secret und OBS-Passwort entgegen, der OAuth-Rueckruf laeuft auf denselben Server. Gespeichert wird verschlueselt (AES-256-GCM) in einem Volume, bewusst nicht in der Datenbank - die wird auf die Windows-Seite gesichert. Siehe ADR-0005. Technikbasis vereinfacht: Node 24 bringt node:sqlite, WebSocket, fetch und die Ausfuehrung von TypeScript mit. Das Projekt hat damit null Laufzeitabhaengigkeiten und keinen Build-Schritt; pnpm-Workspaces und die Paketmanifeste sind entfallen, Importe laufen ueber die imports-Map der Wurzel-package.json. erasableSyntaxOnly verhindert Syntax, die das Type Stripping stillschweigend entfernen wuerde. Siehe Nachtrag 2 in ADR-0001. Enthalten: - packages/core: Config, Layout, Logger mit Secret-Maskierung, Retry, YAML - packages/db: Migrationen, Repositories, alle SQL-Anweisungen an einem Ort - packages/twitch: Secret-Speicher, OAuth, Helix mit Token-Bucket, IRC - apps/ingest: Daemon, Einrichtungsseite, Spike-Erkennung - 20 Tests (IRC-Parser, Spike-Detektor, Datenbankschicht) Der Chat verbindet sich anonym, solange nichts hinterlegt ist - damit laesst sich die Datenaufnahme pruefen, bevor die Twitch-Apps existieren. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_013VTGjd92LsDDWF3frd9FTB
39 lines
1.6 KiB
Markdown
39 lines
1.6 KiB
Markdown
# ADR-0002: SQLite statt Postgres
|
|
|
|
**Status:** akzeptiert · **Datum:** 2026-09-09
|
|
|
|
## Kontext
|
|
|
|
Mehrere Prozesse schreiben und lesen dieselben Daten. Datenvolumen: bei ~10
|
|
Zuschauern und 4 Streams pro Woche etwa 20.000 Chat-Nachrichten und 15.000
|
|
Viewer-Samples pro Monat — wenige MB.
|
|
|
|
## Entscheidung
|
|
|
|
SQLite über das eingebaute **`node:sqlite`** im WAL-Modus, eine Datei im
|
|
Docker-Volume `abdulive-db`.
|
|
|
|
## Begründung
|
|
|
|
- Kein Server, kein Docker, kein Zustand außerhalb einer Datei. Backup ist ein
|
|
Dateikopie-Vorgang (`VACUUM INTO`).
|
|
- WAL erlaubt beliebig viele gleichzeitige Leser neben einem Schreiber. Genau
|
|
unsere Topologie: Der Ingest schreibt, alle anderen lesen.
|
|
- `node:sqlite` ist synchron (`DatabaseSync`), was den Code im Ingest erheblich
|
|
vereinfacht - keine Race Conditions zwischen Ereignisverarbeitung und
|
|
Schreibvorgang.
|
|
- Es ist **in Node 24 enthalten**: keine native Abhaengigkeit, kein node-gyp,
|
|
keine Prebuild-Suche im Docker-Build. Siehe Nachtrag 2 in ADR-0001.
|
|
- Die Datenmenge ist um Größenordnungen von SQLites Grenzen entfernt.
|
|
|
|
## Konsequenzen
|
|
|
|
- **Nur ein schreibender Prozess.** Der Ingest ist der einzige Schreiber für
|
|
`events`, `chat_messages`, `viewer_samples`, `streams`, `user_streams`.
|
|
Andere Apps schreiben ausschließlich in ihre eigenen Tabellen (`clips`,
|
|
`posts`, `redemptions`, `raids`). Diese Aufteilung ist verbindlich.
|
|
- Schreibende Zugriffe immer in Transaktionen bündeln, `busy_timeout` auf 5000 ms.
|
|
- Migration auf Postgres wäre nötig, wenn das Dashboard je remote laufen soll.
|
|
Steht nicht an; die Repository-Schicht in `packages/db` kapselt SQL genug,
|
|
dass es machbar bliebe.
|