8280a9daf9
- ItemEntity, ItemDto: kcalPer100g -> kcalPerKg (kcal_per_kg), minStock-Spalte komplett entfernt - CalculateSupplyRangeUseCase: Formel angepasst (/ 1000.0 * kcalPerKg) - GetMinStockWarningsUseCase + MinStockWarning: gelöscht - UI (ItemFormScreen, WarningsScreen, DashboardScreen): Mindestbestand- Felder und Warnungsabschnitte entfernt - ViewModels, UiState, Repository: alle Referenzen bereinigt - Server (Tables, InventoryRepository): Schema angepasst - Room: fallbackToDestructiveMigration() hinzugefügt (keine Produktivdaten) - Alle 434 Tests gruen
125 lines
6.5 KiB
Markdown
125 lines
6.5 KiB
Markdown
# Technology Candidates – REST-Server für Geräte-Synchronisierung (Phase 2)
|
||
|
||
Date: 2026-05-14
|
||
Requirements file: requirements.md
|
||
|
||
---
|
||
|
||
## Candidate Table
|
||
|
||
| Name | Description | Use case | Age | Adoption | Last release | Update cadence | Req. coverage | Score |
|
||
| ----------------- | --------------------------------------------------- | -------------------------------------------- | ---------------- | --------------------------- | ------------- | -------------- | ------------------------ | ----- |
|
||
| Ktor | Kotlin-nativer async Web-Framework von JetBrains | Microservices, APIs, leichtgewichtige Server | ~8 Jahre (2018) | Moderate (JetBrains-backed) | 2025 (3.x) | Monatlich | Alle Must + alle Should | **9** |
|
||
| Spring Boot | Enterprise-Java/Kotlin-Framework, Industriestandard | Enterprise-Apps, REST-APIs, Microservices | ~12 Jahre (2014) | Widespread | 2025 (3.x) | Monatlich | Alle Must, teilw. Should | **6** |
|
||
| Node.js + Express | JavaScript-Runtime + minimalistisches Web-Framework | APIs, Prototyping, Full-Stack JS | ~15 Jahre (2010) | Widespread | 2025 (5.x) | Regelmäßig | Alle Must, wenig Should | **5** |
|
||
| Python + FastAPI | Modernes Python-Web-Framework mit Type Hints | Schnelle API-Entwicklung, ML-Backends | ~7 Jahre (2018) | Widespread | 2025 (0.115+) | Monatlich | Alle Must, wenig Should | **5** |
|
||
|
||
---
|
||
|
||
## Candidate Details
|
||
|
||
### 1. Ktor (JetBrains)
|
||
|
||
**Homepage:** https://ktor.io
|
||
**Repository:** https://github.com/ktorio/ktor
|
||
|
||
**Requirement coverage:**
|
||
|
||
- ✅ Must: REST-API (JSON), einfaches Deployment (Fat JAR / Docker), CRUD-Unterstützung, JSON via kotlinx.serialization nativ, aktiv gewartet (JetBrains), sehr geringer Ressourcenverbrauch
|
||
- ✅ Should: **Kotlin-nativ** – gleiche Sprache wie Client, Datenmodelle direkt teilbar, kotlinx.serialization als First-Class-Citizen, Coroutines-basiert, kein Application-Server nötig (eingebetteter Netty/CIO), exzellente Dokumentation (ktor.io), einfache DB-Anbindung (Exposed ORM), einfaches Testing
|
||
- ✅ Nice-to-Have: WebSocket-Support eingebaut, Authentifizierungs-Plugins, Docker-ready (Fat JAR), OpenAPI-Plugin verfügbar, Hot-Reload via Auto-Reload-Feature, Type-safe Routing
|
||
|
||
**Stärken:**
|
||
|
||
- **Gleiche Sprache wie der Client** – Datenmodelle (`@Serializable`-Klassen) können in einem Shared-Modul zwischen Server und Client geteilt werden
|
||
- Koroutinen-basiert – konsistent mit dem Android-Client
|
||
- Sehr leichtgewichtig – Start in < 1 Sekunde, wenig RAM
|
||
- JetBrains-maintained – langfristige Pflege gesichert
|
||
- Modulares Plugin-System – nur einbinden was man braucht
|
||
|
||
**Risiken / Schwächen:**
|
||
|
||
- Kleinere Community als Spring Boot – weniger StackOverflow-Antworten
|
||
- Weniger Enterprise-Features out of the box (kein Spring-Ökosystem)
|
||
- Bei komplexen Anforderungen muss man mehr selbst bauen
|
||
|
||
---
|
||
|
||
### 2. Spring Boot
|
||
|
||
**Homepage:** https://spring.io/projects/spring-boot
|
||
**Repository:** https://github.com/spring-projects/spring-boot
|
||
|
||
**Requirement coverage:**
|
||
|
||
- ✅ Must: REST-API, Deployment, CRUD, JSON, aktiv gewartet, stabil
|
||
- ⚠️ Should: Kotlin-Support vorhanden aber nicht nativ (Java-First), kotlinx.serialization nicht Standard (Jackson wird bevorzugt), schwergewichtig (Tomcat eingebettet, hoher RAM-Verbrauch), Coroutines-Support nur via WebFlux
|
||
- ✅ Nice-to-Have: WebSocket, Spring Security, Docker, Swagger/OpenAPI, DevTools Hot-Reload
|
||
|
||
**Stärken:**
|
||
|
||
- Industriestandard mit riesiger Community und Ökosystem
|
||
- Extrem viele Tutorials, Bücher, StackOverflow-Antworten
|
||
- Battle-tested in Produktion bei Millionen von Projekten
|
||
- Spring Security für Authentication/Authorization
|
||
|
||
**Risiken / Schwächen:**
|
||
|
||
- **Overhead für ein kleines Projekt:** Hoher RAM-Verbrauch (200–500 MB), langsame Startzeit, viel Boilerplate
|
||
- **Java-First:** Kotlin ist Second-Class-Citizen – Spring-Idiome (Annotations, Bean-Wiring) fühlen sich in Kotlin weniger natürlich an
|
||
- **Keine geteilten Datenmodelle:** kotlinx.serialization wird nicht nativ unterstützt, Jackson-Annotationen nötig – das Client-Datenmodell kann nicht 1:1 wiederverwendet werden
|
||
- Für 2–10 Nutzer massiv überdimensioniert
|
||
|
||
---
|
||
|
||
### 3. Node.js + Express
|
||
|
||
**Homepage:** https://expressjs.com
|
||
**Repository:** https://github.com/expressjs/express
|
||
|
||
**Requirement coverage:**
|
||
|
||
- ✅ Must: REST-API, einfaches Deployment, CRUD, JSON nativ, aktiv gewartet, geringer Verbrauch
|
||
- ❌ Should: **Andere Sprache (JavaScript/TypeScript)** – keine Wiederverwendung von Kotlin-Datenmodellen, keine Coroutines, kein kotlinx.serialization, andere Toolchain (npm vs. Gradle)
|
||
- ⚠️ Nice-to-Have: WebSocket (via ws/socket.io), Passport.js für Auth, Docker einfach, OpenAPI-Generierung möglich
|
||
|
||
**Stärken:**
|
||
|
||
- Extrem leichtgewichtig und schnell aufzusetzen
|
||
- Riesige Community, npm-Ökosystem
|
||
- Sehr gute Performance für I/O-lastige Workloads
|
||
- Viele fertige Middleware-Pakete
|
||
|
||
**Risiken / Schwächen:**
|
||
|
||
- **Sprachwechsel:** Kotlin (Client) ↔ JavaScript (Server) – kein Code-Sharing, doppelte Modell-Definition
|
||
- **Typsicherheit:** JavaScript bietet weniger Typsicherheit als Kotlin (TypeScript hilft, ist aber ein separates Ökosystem)
|
||
- **Dependency-Overhead:** npm-Ökosystem hat bekannte Supply-Chain-Risiken
|
||
- Separates Tooling und Build-System nötig
|
||
|
||
---
|
||
|
||
### 4. Python + FastAPI
|
||
|
||
**Homepage:** https://fastapi.tiangolo.com
|
||
**Repository:** https://github.com/tiangolo/fastapi
|
||
|
||
**Requirement coverage:**
|
||
|
||
- ✅ Must: REST-API, einfaches Deployment, CRUD, JSON, aktiv gewartet, geringer Verbrauch
|
||
- ❌ Should: **Andere Sprache (Python)** – keine Wiederverwendung von Kotlin-Datenmodellen, kein kotlinx.serialization, andere Toolchain (pip vs. Gradle), kein Coroutines-Bezug
|
||
- ✅ Nice-to-Have: WebSocket-Support, OAuth2-Support, Docker einfach, **automatische OpenAPI/Swagger-Generierung** (Highlight!), Hot-Reload via uvicorn
|
||
|
||
**Stärken:**
|
||
|
||
- Extrem schnelle Entwicklung dank Auto-Dokumentation und Type Hints
|
||
- Automatische OpenAPI-Doku out of the box
|
||
- Async I/O via asyncio
|
||
- Gut für Prototyping
|
||
|
||
**Risiken / Schwächen:**
|
||
|
||
- **Sprachwechsel:** Kotlin ↔ Python – komplett andere Toolchain, kein Code-Sharing
|
||
- **GIL:** Python Global Interpreter Lock kann bei CPU-intensiven Operationen limitieren (hier aber irrelevant)
|
||
- **Deployment:** Python-Umgebungen können fragiler sein als JVM-Fat-JARs (venv, pip-Abhängigkeiten)
|
||
- Weniger natürliche Integration mit dem Kotlin/Gradle-basierten Projekt
|