# ADR: Server-Technologie für Geräte-Synchronisierung

**Status:** Akzeptiert
**Datum:** 2026-05-14
**Issue:** #10

---

## Kontext

Die Bollwerk-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
