30 lines
1.7 KiB
Markdown
30 lines
1.7 KiB
Markdown
# ADR-0001: Tech-Stack für Shuffle
|
||
|
||
- **Status:** Angenommen (Chris, 2026-11-02)
|
||
- **Datum:** 2026-11-01
|
||
|
||
## Kontext
|
||
Shuffle soll auf iOS, Android und im Web laufen, von einer Person mit KI-Agents entwickelt werden
|
||
und Daten DSGVO-konform in der EU halten. Code liegt in Forgejo, Doku in Outline (beides selbst gehostet).
|
||
|
||
## Optionen
|
||
### Frontend
|
||
- **Flutter** – eine Codebasis für alle drei Plattformen, starke Typisierung, gute Testbarkeit, sehr gute Agent-Unterstützung (Dart-MCP-Server). Web-Build ist eher App-artig als SEO-optimiert.
|
||
- **React Native + Expo** – großes Ökosystem, Web über react-native-web; mehr Plattform-Sonderfälle.
|
||
- **Getrennte Web-App (z. B. Next.js) + Flutter mobil** – bestes Web/SEO, aber doppelter Aufwand.
|
||
|
||
### Backend
|
||
- **Supabase** – PostgreSQL mit Auth, Storage, Realtime, Edge Functions; selbst hostbar (Docker) oder EU-Region; Berechtigungen per Row Level Security direkt in der DB.
|
||
- **Appwrite** – ähnlich, selbst hostbar, NoSQL-artiges Modell.
|
||
- **Eigenes Backend (z. B. Dart/Go/Node + PostgreSQL)** – maximale Kontrolle, deutlich mehr Aufwand.
|
||
|
||
## Entscheidung (Vorschlag)
|
||
**Flutter + Supabase**, State mit Riverpod, Navigation mit go_router, Modelle mit freezed.
|
||
Hosting: Supabase selbst gehostet oder in EU-Region; Web-Build statisch hinter Reverse Proxy.
|
||
|
||
## Konsequenzen
|
||
- Eine Codebasis, ein Testansatz, schneller MVP.
|
||
- Relationales Modell passt gut zu Sammlungen, Spielabenden, Freundschaften.
|
||
- Sicherheit hängt an sauberen RLS-Policies → Pflicht-Tests (pgTAP) in jedem Feature.
|
||
- Öffentliche, suchmaschinenrelevante Seiten (z. B. Landingpage) ggf. separat lösen.
|
||
- iOS-Builds benötigen einen Mac (lokal oder macOS-Runner).
|