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.4 KiB

Raw Blame History

Technology Requirements – REST-Server für Geräte-Synchronisierung (Phase 2)

Date: 2026-05-14 Issue: #10 Author: Tech-Decision Workflow

Kontext

Die Bollwerk-App (Android/Kotlin) speichert in v1.0 alle Daten lokal (Room/SQLite). In Phase 2 soll ein REST-Server hinzukommen, der die Synchronisierung und das Sharing des Inventars zwischen mehreren Geräten ermöglicht.

Einsatzszenario:

Privater Gebrauch, kein kommerzieller Betrieb
Wenige Geräte (2–10), keine hohe Last
Während Entwicklung: Server lokal auf Laptop, Testgerät im LAN
Später: kleiner Server im Internet (VPS / Homeserver)
Datenformat: JSON (kotlinx.serialization, bereits im Client definiert)

Vom Issue genannte Optionen: Ktor, Spring Boot, Node.js/Express, Python/FastAPI

Must-Have (Eliminatoren)

REST-API bereitstellen (JSON Request/Response)
Einfaches Deployment auf einem kleinen Linux-VPS oder Homeserver
Unterstützung für grundlegende CRUD-Operationen (Inventar-Items, Kategorien, Lagerorte)
JSON als primäres Datenformat (kompatibel mit dem bestehenden Client-Datenmodell)
Aktiv gewartet, stabile Release-Versionen verfügbar
Geringe Betriebskosten (wenig RAM/CPU-Verbrauch für wenige Nutzer)

Should-Have (gewichtete Pluspunkte)

Kotlin-Kompatibilität: Gleiche Sprache wie der Android-Client (Wiederverwendung von Datenmodellen, kotlinx.serialization)
Einfache Einrichtung und geringer Boilerplate
Integrierte Unterstützung für Coroutines / async I/O
Leichtgewichtig (kein Application-Server wie Tomcat nötig)
Gute Dokumentation und Lernressourcen
Einfache Datenbankanbindung (SQLite oder PostgreSQL)
Einfaches Testen (Unit- und Integrationstests)

Nice-to-Have (Bonus)

WebSocket-Unterstützung (für Echtzeit-Sync in einer späteren Phase)
Eingebaute Authentifizierung / Sicherheitsmechanismen
Docker-Image oder einfache Containerisierung
OpenAPI / Swagger-Generierung
Hot-Reload / schnelle Entwicklungszyklen
Type-safe Routing

Constraints

Zielplattform Server: Linux (VPS / Homeserver), optional auch Windows/macOS für lokale Entwicklung
Client-Sprache: Kotlin (Android) – geteilte Modelle sind ein großer Vorteil
Serialisierung: kotlinx.serialization (bereits im Client im Einsatz)
Lizenz: Open Source (MIT, Apache 2.0 o.ä.)
Skalierung: Nicht relevant – max. 10 gleichzeitige Nutzer
Budget: Kein Budget für kommerzielle Lizenzen oder teure Hosting-Lösungen

2.4 KiB Raw Blame History Unescape Escape