Stefan Mogeritsch
35da070893
Enabled Wasm target across all relevant modules and removed conditional enablement logic. Refactored `core:core-utils` to move JVM-specific code to a new `backend:infrastructure:persistence` module for strict KMP compliance. Updated dependencies, adjusted Gradle configurations, and resolved circular dependencies.
60 lines
3.9 KiB
Markdown
60 lines
3.9 KiB
Markdown
# Architecture & Build Status Report
|
|
**Datum:** 09.01.2026
|
|
**Von:** Senior Backend Developer
|
|
**An:** Lead Software Architect
|
|
|
|
## 1. Executive Summary
|
|
Wir haben eine umfassende Stabilisierung der Projekt-Architektur durchgeführt. Kritische Versionskonflikte im Backend (Spring Boot vs. Spring Cloud) wurden behoben. Die Trennung zwischen Frontend (KMP) und Backend (JVM) wurde durch Refactoring des `core`-Bereichs strikt durchgesetzt, um "Pollution" durch JVM-Code im Frontend zu verhindern.
|
|
|
|
Der Build-Prozess ist derzeit noch durch spezifische **Kotlin/Wasm Kompilierungsfehler** blockiert, die aus der strikten Typisierung und dem JS-Interop von WebAssembly resultieren.
|
|
|
|
---
|
|
|
|
## 2. Durchgeführte Maßnahmen
|
|
|
|
### 2.1 Backend Architecture Alignment
|
|
* **Spring Cloud Konflikt gelöst:** Downgrade von `2025.1.0` (Oakwood, inkompatibel mit Boot 3.5) auf **`2025.0.1` (Northfields)**. Dies verhindert garantierte Laufzeitfehler (`NoSuchMethodError`).
|
|
* **Java 25 Optimierung:** Upgrade von Micrometer auf `1.16.1` für besseren Virtual Thread Support.
|
|
* **Exposed Versionierung:** Bestätigung der Nutzung von `1.0.0-rc-4` (statt der veralteten 0.61.0).
|
|
|
|
### 2.2 Modul-Hygiene & KMP Trennung
|
|
* **Refactoring `core:core-utils`:**
|
|
* Das Modul enthielt JVM-spezifischen Code (`DatabaseUtils.kt` mit Exposed-Abhängigkeiten), der den Frontend-Build (JS/Wasm) brach.
|
|
* **Lösung:** Erstellung eines neuen Moduls **`:backend:infrastructure:persistence`**. Der DB-Code wurde dorthin verschoben. `core:core-utils` ist nun ein reines KMP-Modul.
|
|
* **Zirkuläre Abhängigkeiten aufgelöst:**
|
|
* Das Modul `frontend:shared` hatte Abhängigkeiten zu Feature-Modulen und dem Design-System, was zu Zyklen führte.
|
|
* **Lösung:** `frontend:shared` wurde bereinigt und dient nun rein als Basis-Layer (Config, Utils).
|
|
|
|
### 2.3 Build-System (Gradle & KMP)
|
|
* **Wasm-Target Konsolidierung:**
|
|
* Um Inkonsistenzen bei der Dependency Resolution zu beheben, wurde das Target `wasmJs` **projektweit** in allen relevanten KMP-Modulen (`core`, `frontend`) aktiviert.
|
|
* Dies löste die `Unresolved platforms: [wasmJs]` Fehler.
|
|
|
|
---
|
|
|
|
## 3. Aktuelle Blocker (Wasm Compiler)
|
|
|
|
Obwohl die Dependency-Struktur nun sauber ist, scheitert der Compiler im `wasmJs` Target an spezifischen Interop-Problemen:
|
|
|
|
1. **Fehlende Referenzen (`Unresolved reference`):**
|
|
* `org.w3c.dom.Worker` und `kotlinx.browser.window` werden im Wasm-Kontext nicht gefunden.
|
|
* *Ursache:* Kotlin/Wasm benötigt möglicherweise explizite Imports oder externe Deklarationen für bestimmte DOM-APIs, die in Kotlin/JS implizit waren, oder die Standard-Bibliothek wird nicht korrekt eingebunden.
|
|
2. **JS-Interop Einschränkungen:**
|
|
* Fehler: `Type 'ERROR CLASS: Symbol not found for Worker' cannot be used as return type`.
|
|
* Kotlin/Wasm erlaubt keine komplexen `js("...")` Blöcke innerhalb von Funktionen und hat keinen `dynamic` Typ. Unsere ersten Fixes (Helper-Funktionen) waren ein Schritt in die richtige Richtung, aber die Typen (wie `Worker`) müssen dem Compiler bekannt gemacht werden.
|
|
|
|
---
|
|
|
|
## 4. Nächste Schritte (Plan)
|
|
|
|
1. **Wasm-Build reparieren:**
|
|
* Prüfen, ob wir eine explizite Dependency (z.B. `kotlinx-browser` oder `kotlin-stdlib-wasm-js`) benötigen.
|
|
* Falls `Worker` in der Wasm-Stdlib fehlt: Definition einer `external class Worker` für Wasm erstellen, um dem Compiler den Typ bekannt zu machen.
|
|
2. **Backend-Verifikation ("Bauplan"):**
|
|
* Sobald der Build durchläuft (oder wir das Frontend temporär exkludieren), werde ich den **`ping-service`** starten.
|
|
* Ziel: Nachweis, dass Spring Context, Datenbank-Verbindung (JPA) und die neue Modul-Struktur (`backend:infrastructure:persistence`) zur Laufzeit funktionieren.
|
|
3. **Sync-Strategie:**
|
|
* Anschließend widmen wir uns der im Frontend-Report erwähnten "Offline-Sync"-Logik (basierend auf UUIDv7).
|
|
|
|
**Empfehlung:** Wir sollten den Wasm-Build-Fix priorisieren, da er aktuell das gesamte Projekt blockiert ("Fail Fast").
|