bollwerkadmin/bollwerk
1
0
Fork 0
Code Issues 12 Pull requests Projects Releases Packages Wiki Activity Actions
bollwerk/Anforderungen/design/server-tech/adr-server-technology.md
Jens Reinemann a5f89e6a69 rename: Krisenvorrat -> Bollwerk 
- Package: de.krisenvorrat.* -> de.bollwerk.*
- Klassen: KrisenvorratApp/Database/Theme -> Bollwerk*
- ApplicationId: de.bollwerk.app
- Server: BOLLWERK_* Env-Vars, bollwerk HOCON-Config
- Docker: bollwerk-server/db/backup Container-Namen
- Room DB: bollwerk.db, SharedPrefs: bollwerk_secure_prefs
- Export-Dateien: bollwerk_export/inventar
- UI-Strings, HTML, Admin-UI: alle auf Bollwerk
- Docs, Skills, README angepasst
- Alle Tests gruen, Build erfolgreich
2026-05-17 17:44:02 +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 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