# 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