bollwerkadmin/bollwerk
1
0
Fork 0
Code Issues 11 Pull requests Projects Releases Packages Wiki Activity Actions
bollwerk/Anforderungen/design/server-tech/candidates.md
Jens Reinemann 8280a9daf9 refactor: kcal/100g -> kcal/kg umbenennen und Mindestbestand entfernen 
- 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
2026-05-16 14:19:10 +02:00

6.5 KiB
Raw Blame History

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