bollwerk/Anforderungen/design/server-tech/requirements.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

60 lines
2.4 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# 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 (210), 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