bollwerkadmin/bollwerk
1
0
Fork 0
Code Issues 8 Pull requests Projects Releases Packages Wiki Activity Actions
bollwerk/Anforderungen/design/server-tech/adr-server-technology.md
Jens Reinemann 309587bc36 docs(server-tech): ADR für Server-Technologie – Ktor gewählt 
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
2026-05-14 19:22:27 +02:00

2.8 KiB
Raw Blame History

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