- 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
60 lines
2.4 KiB
Markdown
60 lines
2.4 KiB
Markdown
# 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
|