309587bc36
Anforderungen/design/server-tech/adr-server-technology.md: Architecture Decision Record für die Server-Technologie in Phase 2 (Geräte-Synchronisierung). Ktor gewählt wegen gleicher Sprache (Kotlin), kotlinx.serialization-Kompatibilität, Code-Sharing- Möglichkeit, geringem Ressourcenverbrauch und JetBrains-Support. Geprüfte Alternativen: Spring Boot, Node.js+Express, Python+FastAPI. Closes #10
56 lines
2.8 KiB
Markdown
56 lines
2.8 KiB
Markdown
# ADR: Server-Technologie für Geräte-Synchronisierung
|
||
|
||
**Status:** Akzeptiert
|
||
**Datum:** 2026-05-14
|
||
**Issue:** #10
|
||
|
||
---
|
||
|
||
## Kontext
|
||
|
||
Die Krisenvorrat-App (Android/Kotlin) benötigt in Phase 2 einen REST-Server für die Synchronisierung und das Sharing des Inventars zwischen mehreren Geräten. Der Server wird im privaten Umfeld eingesetzt (2–10 Geräte, wenig Last) und soll einfach auf einem kleinen Linux-VPS oder Homeserver deploybar sein.
|
||
|
||
Das bestehende Client-Datenmodell nutzt kotlinx.serialization für JSON-Export/Import.
|
||
|
||
## Entscheidung
|
||
|
||
**Gewählt: Ktor** (Kotlin-nativer Server von JetBrains)
|
||
|
||
## Begründung
|
||
|
||
1. **Gleiche Sprache wie der Client:** Ktor ist in Kotlin geschrieben und ermöglicht die direkte Wiederverwendung von Datenmodellen (`@Serializable`-Klassen) zwischen Android-Client und Server – idealerweise in einem Shared-Modul.
|
||
|
||
2. **kotlinx.serialization als First-Class-Citizen:** Das bestehende Client-Datenmodell nutzt bereits kotlinx.serialization. Ktor unterstützt dies nativ, sodass keine zusätzliche Serialisierungs-Bibliothek (wie Jackson bei Spring Boot) nötig ist.
|
||
|
||
3. **Koroutinen-basiert:** Konsistent mit dem Android-Client, der ebenfalls Kotlin Coroutines verwendet. Gleiche Konzepte, gleiche Patterns.
|
||
|
||
4. **Leichtgewichtig:** Start in unter 1 Sekunde, geringer RAM-Verbrauch. Kein Application-Server nötig (eingebetteter Netty/CIO). Ideal für den geplanten Einsatz auf einem kleinen VPS oder Homeserver.
|
||
|
||
5. **JetBrains-Support:** Langfristige Pflege durch JetBrains gesichert. Monatliche Releases, aktive Weiterentwicklung (aktuell Version 3.x).
|
||
|
||
6. **Modulares Plugin-System:** Nur einbinden was man braucht – kein unnötiger Overhead.
|
||
|
||
## Geprüfte Alternativen
|
||
|
||
### Spring Boot (Score: 6/10)
|
||
|
||
- **Pro:** Industriestandard, riesige Community, umfangreiches Ökosystem
|
||
- **Contra:** Java-First (Kotlin ist Second-Class-Citizen), hoher Overhead (RAM, Startzeit) für ein kleines Projekt, kotlinx.serialization nicht nativ unterstützt (Jackson bevorzugt), keine direkte Wiederverwendung der Client-Datenmodelle
|
||
|
||
### Node.js + Express (Score: 5/10)
|
||
|
||
- **Pro:** Leichtgewichtig, schnelles Prototyping, große Community
|
||
- **Contra:** Sprachwechsel Kotlin ↔ JavaScript, kein Code-Sharing möglich, doppelte Modell-Definition nötig, npm Supply-Chain-Risiken
|
||
|
||
### Python + FastAPI (Score: 5/10)
|
||
|
||
- **Pro:** Schnelle Entwicklung, automatische OpenAPI-Doku, async I/O
|
||
- **Contra:** Sprachwechsel Kotlin ↔ Python, kein Code-Sharing, andere Toolchain, fragiles Deployment (venv/pip)
|
||
|
||
## Konsequenzen
|
||
|
||
- Der Server wird als Kotlin/Ktor-Projekt aufgesetzt
|
||
- Datenmodelle können in einem Shared-Modul zwischen Client und Server geteilt werden
|
||
- kotlinx.serialization wird sowohl auf Client- als auch Server-Seite verwendet
|
||
- Exposed ORM wird für die Datenbankanbindung evaluiert
|
||
- Deployment als Fat JAR oder Docker-Container
|