chore: entferne veraltete Architekturdokumente
Signed-off-by: StefanMoCoAt <stefan.mo.co@gmail.com>
This commit is contained in:
@@ -1,60 +0,0 @@
|
||||
---
|
||||
type: Report
|
||||
status: ACTIVE
|
||||
owner: Backend Developer
|
||||
last_update: 2026-02-01
|
||||
---
|
||||
|
||||
# Abschlussbericht: Backend Hardening & Infrastructure (Ping-Service)
|
||||
|
||||
## 1. Management Summary
|
||||
Der **Ping-Service** wurde erfolgreich als technischer Blueprint ("Tracer Bullet") gehärtet. Er erfüllt nun alle Anforderungen der **Phase 1 (Backend Hardening)** der Q1 Roadmap.
|
||||
Die Infrastruktur wurde modernisiert (Valkey 9.0), und die Testabdeckung wurde durch echte Integrationstests (Testcontainers) auf ein Enterprise-Niveau gehoben.
|
||||
|
||||
Der Service ist **Production Ready** und dient ab sofort als Vorlage für alle fachlichen Microservices.
|
||||
|
||||
## 2. Durchgeführte Maßnahmen
|
||||
|
||||
### 🛡️ Security & Resilience
|
||||
* **OAuth2 Resource Server:** Implementiert und konfiguriert (`GlobalSecurityConfig`). Tokens vom Keycloak werden validiert.
|
||||
* **RBAC:** Endpunkte wie `/ping/secure` sind durch Rollen geschützt (`@PreAuthorize`).
|
||||
* **CircuitBreaker:** Resilience4j sichert DB-Zugriffe ab (`@CircuitBreaker`). Fallback-Methoden ("Degraded Mode") sind aktiv.
|
||||
|
||||
### 🏗️ Infrastructure Upgrade
|
||||
* **Valkey Migration:** Erfolgreiche Migration von Redis (proprietär) auf **Valkey 9.0** (Open Source) in `docker-compose` und Environment-Configs.
|
||||
* Images: `valkey/valkey:9.0`
|
||||
* Kompatibilität: Vollständig gegeben (Drop-In Replacement).
|
||||
|
||||
### 🧪 Quality Assurance (Testing)
|
||||
* **Integrationstests:** Implementierung von `PingRepositoryTest` mit **Testcontainers** (Postgres).
|
||||
* Prüft Flyway-Migrationen (`V1`, `V2`).
|
||||
* Prüft JPA-Mapping und UUIDv7-Persistenz gegen eine echte Datenbank.
|
||||
* **Test-Isolierung:** Lösung komplexer Spring-Kontext-Probleme (`BeanDefinitionOverrideException`) durch:
|
||||
* Einführung einer isolierten `TestPersistenceConfig` für Repository-Tests.
|
||||
* Nutzung von `@TestConfiguration` in Controller-Tests.
|
||||
* Entfernung des hinderlichen `@Profile("!test")` im `PingRepositoryAdapter`.
|
||||
|
||||
### 📊 Observability
|
||||
* **Actuator:** Health, Info, Metrics und Prometheus-Endpunkte sind exponiert.
|
||||
* **Tracing:** Zipkin-Integration vorbereitet via `monitoring-client`.
|
||||
|
||||
## 3. Technische Details & Learnings
|
||||
|
||||
### Problem: Spring Context Pollution
|
||||
Während der Implementierung der Integrationstests kam es zu Konflikten zwischen den Bean-Definitionen verschiedener Tests (`BeanDefinitionOverrideException`).
|
||||
**Lösung:**
|
||||
Strikte Trennung der Kontexte. `PingRepositoryTest` lädt nun **nicht** mehr die gesamte `PingServiceApplication`, sondern nur eine minimale `TestPersistenceConfig`, die gezielt nur das Persistence-Layer scannt. Dies beschleunigt die Tests und verhindert Seiteneffekte durch Controller oder Security-Configs.
|
||||
|
||||
### Problem: Profile-Exclusion
|
||||
Der `PingRepositoryAdapter` war mit `@Profile("!test")` annotiert. Dies verhinderte, dass Integrationstests (die im `test`-Profil laufen) den echten Adapter nutzen konnten.
|
||||
**Lösung:**
|
||||
Annotation entfernt. In Unit-Tests wird der Adapter ohnehin durch Mocks ersetzt, daher ist die Exclusion unnötig und schädlich für Integrationstests.
|
||||
|
||||
## 4. Nächste Schritte (Handover an Frontend)
|
||||
Der Backend-Stack ist stabil. Der Frontend-Expert kann nun die Integration (Phase 2) abschließen:
|
||||
1. Login gegen Keycloak.
|
||||
2. Aufruf von `/ping/secure` mit Bearer-Token.
|
||||
3. Test des Delta-Syncs (`/ping/sync`).
|
||||
|
||||
---
|
||||
*Gez. Senior Backend Developer*
|
||||
@@ -1,59 +0,0 @@
|
||||
---
|
||||
type: Report
|
||||
status: ACTIVE
|
||||
owner: Frontend Expert
|
||||
title: Frontend Cleanup & Architecture Status Report
|
||||
date: 2026-02-01
|
||||
author: Frontend Expert & Curator
|
||||
tags: [frontend, architecture, cleanup, kmp, compose]
|
||||
---
|
||||
|
||||
# 🧹 Frontend Cleanup & Architecture Status Report
|
||||
|
||||
## 1. Executive Summary
|
||||
Dieses Dokument fasst die umfangreichen Aufräum- und Refactoring-Arbeiten am Frontend ("Meldestelle Portal") zusammen. Ziel war es, technischen Ballast ("Dead Code") zu entfernen, die Architektur zu vereinheitlichen (MVVM + Clean Architecture) und die Kompilierbarkeit über alle Plattformen (JVM/Desktop & JS/Web) sicherzustellen.
|
||||
|
||||
**Ergebnis:** Der Build ist erfolgreich (`BUILD SUCCESSFUL`). Das Frontend ist nun schlank, wartbar und bereit für die Feature-Entwicklung.
|
||||
|
||||
## 2. Durchgeführte Maßnahmen
|
||||
|
||||
### 2.1. Entfernung von "Dead Code"
|
||||
* **`frontend/shared` gelöscht:** Dieses Modul enthielt einen kompletten, ungenutzten Redux-Stack (`AppStore`, `AppAction`, etc.), der im Widerspruch zur genutzten MVVM-Architektur stand.
|
||||
* **Legacy-Komponenten entfernt:** Veraltete UI-Komponenten (z.B. `NotificationCard.kt`) und doppelte Navigations-Konzepte wurden bereinigt.
|
||||
|
||||
### 2.2. Architektur-Konsolidierung
|
||||
* **MVVM als Standard:** Die Anwendung folgt nun strikt dem MVVM-Muster mit Kotlin Coroutines (`StateFlow`) und Koin für Dependency Injection.
|
||||
* **Clean Architecture:** Das `ping-feature` dient als Referenz-Implementierung mit klarer Trennung von `Presentation`, `Domain` und `Data` Layer.
|
||||
* **Navigation:** Zentralisierung der Navigation auf `AppScreen` (Sealed Class) im Core-Modul.
|
||||
|
||||
### 2.3. Build & Plattform-Support
|
||||
* **Koin-Initialisierung:** Korrektur der Koin-Start-Logik für JVM (`startKoin` statt `initKoin`) und JS (`startKoin` im `main.kt`).
|
||||
* **Gradle-Konfiguration:** Bereinigung der `build.gradle.kts` Dateien und Entfernung von Abhängigkeiten zu gelöschten Modulen.
|
||||
* **Web-Support:** Sicherstellung, dass die Web-Version (Kotlin/JS) fehlerfrei baut und die Datenbank (SQLDelight Wasm) korrekt initialisiert.
|
||||
|
||||
## 3. Modul-Status (Ist-Zustand)
|
||||
|
||||
| Modul | Status | Beschreibung |
|
||||
| :--- | :--- | :--- |
|
||||
| **`core/navigation`** | ✅ Grün | Zentrale Routen (`AppScreen`, `Routes`), DeepLink-Handling. Sauber. |
|
||||
| **`core/design-system`** | ✅ Grün | UI-Komponenten (`AppTheme`, `Buttons`, `Inputs`). Modern (Material 3). |
|
||||
| **`core/auth`** | ✅ Grün | Login-Logik, Token-Manager, API-Client. Funktional. |
|
||||
| **`core/network`** | ✅ Grün | Zentraler `HttpClient` mit Auth-Interceptor. |
|
||||
| **`core/sync`** | ✅ Grün | Generischer `SyncManager` für Offline-First. |
|
||||
| **`core/local-db`** | ✅ Grün | SQLDelight Setup für JVM & Web. |
|
||||
| **`features/ping`** | ✅ Grün | **Blueprint-Feature**. Zeigt Best Practices (Sync, UI, DI). |
|
||||
| **`shells/portal`** | ✅ Grün | Einstiegspunkt (`MainApp`). Verbindet alle Module. |
|
||||
|
||||
## 4. Offene Punkte & Nächste Schritte
|
||||
|
||||
Obwohl der technische Zustand nun exzellent ist, gibt es logische nächste Schritte für die Produktentwicklung:
|
||||
|
||||
1. **Feature-Rollout:** Implementierung des `members-feature` (Mitglieder) basierend auf dem `ping-feature` Blueprint.
|
||||
2. **Testing:** Etablierung von Unit-Tests für die Core-Logik (Auth, Sync) und UI-Tests für kritische Flows.
|
||||
3. **Backend-Alignment:** Sicherstellung, dass die Backend-Services (Registry) die erwarteten Sync-Endpunkte bereitstellen.
|
||||
|
||||
## 5. Fazit
|
||||
Das Frontend-Fundament ist stabil. Die "technischen Schulden" aus der Experimentierphase (Redux vs. MVVM) sind getilgt. Das Team kann sich nun voll auf die Implementierung der fachlichen Anforderungen konzentrieren.
|
||||
|
||||
---
|
||||
*Gez. Frontend Expert & Curator*
|
||||
@@ -1,34 +0,0 @@
|
||||
---
|
||||
type: Report
|
||||
status: ACTIVE
|
||||
owner: Curator
|
||||
date: 2026-02-01
|
||||
author: Curator
|
||||
---
|
||||
|
||||
# Report: Fix Sync Type Mismatch (String vs Long)
|
||||
|
||||
## 1. Problembeschreibung
|
||||
Es wurde eine kritische Inkonsistenz im Delta-Sync-Mechanismus zwischen Frontend und Backend festgestellt.
|
||||
* **Frontend:** Der generische `SyncManager` nutzte einen String-Cursor (UUIDv7), was zu einem Typ-Fehler führte.
|
||||
* **Backend:** Der `PingController` erwartete strikt einen `Long` (Timestamp) für den Parameter `lastSyncTimestamp`.
|
||||
|
||||
## 2. Durchgeführte Maßnahmen
|
||||
### 2.1 Backend (`ping-service`)
|
||||
* **Parameter-Umbenennung:** Der Parameter im `PingController` wurde von `lastSyncTimestamp` zu `since` umbenannt, um der Konvention des Frontend-SyncManagers zu entsprechen.
|
||||
* **Tests:** Unit- und Integrationstests (`PingControllerTest`) wurden aktualisiert.
|
||||
|
||||
### 2.2 Frontend (`meldestelle-portal`)
|
||||
* **Repository-Anpassung:** `PingEventRepositoryImpl` holt nun explizit den `last_modified` Timestamp aus der Datenbank (via neuer SQL-Query `selectLatestPingEventTimestamp`).
|
||||
* **Typ-Konvertierung:** Der Timestamp wird als String an den `SyncManager` übergeben, der ihn als URL-Parameter anhängt. Spring Boot konvertiert diesen String automatisch zurück in einen `Long`.
|
||||
|
||||
### 2.3 Contracts (`ping-api`)
|
||||
* Das Interface `PingApi` wurde aktualisiert: `syncPings(since: Long)`.
|
||||
|
||||
## 3. Ergebnis
|
||||
* Die Typ-Sicherheit ist hergestellt.
|
||||
* Tests im Backend laufen erfolgreich durch.
|
||||
* Der Sync-Mechanismus ist nun robust und bereit für den produktiven Einsatz.
|
||||
|
||||
## 4. Status
|
||||
✅ **RESOLVED**
|
||||
@@ -1,52 +0,0 @@
|
||||
---
|
||||
type: Report
|
||||
status: ARCHIVED
|
||||
author: Senior Backend Developer
|
||||
date: 2026-01-17
|
||||
context: Phase 3 - Sync Implementation
|
||||
---
|
||||
|
||||
# Backend Status Report: Phase 3 (Sync) abgeschlossen
|
||||
|
||||
**ARCHIVED:** This report reflects a past state. Please refer to `2026-01-23_Weekend_Status_Report.md` for the current status.
|
||||
|
||||
---
|
||||
|
||||
## 1. Zusammenfassung
|
||||
Die Phase 3 der "Operation Tracer Bullet" wurde erfolgreich abgeschlossen. Der `PingService` wurde um Delta-Sync-Funktionalität erweitert, um Offline-First-Clients effizient zu unterstützen.
|
||||
|
||||
**Wichtigste Errungenschaften:**
|
||||
* **Delta-Sync API:** Implementierung von `/ping/sync` basierend auf Zeitstempeln.
|
||||
* **Contract-Update:** Synchronisierung der API-Definitionen zwischen Backend und Frontend (`:contracts:ping-api`).
|
||||
* **Testing:** Vollständige Testabdeckung für die neuen Sync-Endpunkte.
|
||||
|
||||
---
|
||||
|
||||
## 2. Technische Details
|
||||
|
||||
### A. Sync-Strategie
|
||||
* **Mechanismus:** Zeitstempel-basierter Delta-Sync.
|
||||
* **API:** `GET /ping/sync?lastSyncTimestamp={epochMillis}`
|
||||
* **Response:** Liste von `PingEvent` (ID, Message, LastModified).
|
||||
* **Vorteil:** Clients laden nur geänderte Daten, was Bandbreite spart und Offline-Fähigkeit unterstützt.
|
||||
|
||||
### B. Implementierung
|
||||
* **Domain:** Erweiterung des `PingUseCase` um `getPingsSince(timestamp: Long)`.
|
||||
* **Persistence:** Effiziente JPA-Query `findByCreatedAtAfter` auf dem `timestamp`-Index.
|
||||
* **Security:** Der Sync-Endpunkt ist aktuell `public` (analog zu anderen Ping-Endpunkten), kann aber bei Bedarf geschützt werden.
|
||||
|
||||
### C. Frontend-Kompatibilität
|
||||
* Die Frontend-Clients (`PingApiClient`, `PingApiKoinClient`) wurden aktualisiert, um den neuen Endpunkt zu unterstützen.
|
||||
* Test-Doubles im Frontend wurden angepasst, um die Build-Integrität zu wahren.
|
||||
|
||||
---
|
||||
|
||||
## 3. Offene Punkte & Nächste Schritte
|
||||
|
||||
* **Frontend Integration:** Der Frontend-Expert muss nun die Logik implementieren, um den `lastSyncTimestamp` lokal zu speichern und den Sync-Prozess zu steuern.
|
||||
* **Konfliktlösung:** Aktuell ist der Sync unidirektional (Server -> Client). Für bidirektionalen Sync (Client -> Server) müssen noch Strategien (z.B. "Last Write Wins") definiert werden.
|
||||
|
||||
---
|
||||
|
||||
## 4. Fazit
|
||||
Das Backend ist bereit für Offline-First-Szenarien. Die Delta-Sync-Schnittstelle ist performant und einfach zu konsumieren.
|
||||
+7
-2
@@ -6,10 +6,10 @@ date: 2026-01-31
|
||||
tags: [e2e, smoke, docker, migration, ktor-3.4.0, exposed-1.0.0]
|
||||
---
|
||||
|
||||
|
||||
# E2E Smoke – Migration Exposed 1.0.0 & Ktor 3.4.0
|
||||
|
||||
## Einrichtung
|
||||
|
||||
- Compose: docker compose --profile all up --build -d
|
||||
- Services (Auszug):
|
||||
- api-gateway (8080/actuator, 8080/api via Proxy)
|
||||
@@ -20,17 +20,22 @@ tags: [e2e, smoke, docker, migration, ktor-3.4.0, exposed-1.0.0]
|
||||
- Versionen (Platform/Catalog): ktor=3.4.0, exposed=1.0.0
|
||||
|
||||
## Checks & Ergebnisse
|
||||
|
||||
- Gateway Health: 200 OK (readiness/live, Prometheus)
|
||||
- Ping-Service Health/Prometheus: 200 OK stabil
|
||||
- Web-App Health: 200 OK (Fallback-Assets aktiv, Favicon bereitgestellt)
|
||||
- Desktop-App: Xvfb/XFCE/x11vnc/noVNC aktiv, Zugriff via http://localhost:6080/
|
||||
|
||||
## Beobachtbarkeit
|
||||
|
||||
- Prometheus-Metriken erreichbar (Gateway/Ping)
|
||||
- Logs ohne kritische Fehler im Happy Path
|
||||
|
||||
## Probleme & Hinweise
|
||||
- Frontend KMP/JS-Build schlägt in Builder aktuell fehl (fehlende JS-Implementierungen in Auth/Ping-Data). Nginx liefert Fallback-Assets aus; Favicon hinzugefügt, um 404 zu vermeiden.
|
||||
|
||||
- Frontend KMP/JS-Build schlägt in Builder aktuell fehl (fehlende JS-Implementierungen in Auth/Ping-Data). Nginx liefert
|
||||
Fallback-Assets aus; Favicon hinzugefügt, um 404 zu vermeiden.
|
||||
|
||||
## Entscheidung
|
||||
|
||||
- Empfehlung: Go für Phase 4 (FE „web“-Target Migration & Build-Fix; Dokumente finalisieren)
|
||||
@@ -0,0 +1,79 @@
|
||||
---
|
||||
type: Report
|
||||
status: ACTIVE
|
||||
owner: Backend Developer
|
||||
last_update: 2026-02-01
|
||||
---
|
||||
|
||||
# Abschlussbericht: Backend Hardening & Infrastructure (Ping-Service)
|
||||
|
||||
## 1. Management Summary
|
||||
|
||||
Der **Ping-Service** wurde erfolgreich als technischer Blueprint ("Tracer Bullet") gehärtet. Er erfüllt nun alle
|
||||
Anforderungen der **Phase 1 (Backend Hardening)** der Q1 Roadmap.
|
||||
Die Infrastruktur wurde modernisiert (Valkey 9.0), und die Testabdeckung wurde durch echte Integrationstests (
|
||||
Testcontainers) auf ein Enterprise-Niveau gehoben.
|
||||
|
||||
Der Service ist **Production Ready** und dient ab sofort als Vorlage für alle fachlichen Microservices.
|
||||
|
||||
## 2. Durchgeführte Maßnahmen
|
||||
|
||||
### 🛡️ Security & Resilience
|
||||
|
||||
* **OAuth2 Resource Server:** Implementiert und konfiguriert (`GlobalSecurityConfig`). Tokens vom Keycloak werden
|
||||
validiert.
|
||||
* **RBAC:** Endpunkte wie `/ping/secure` sind durch Rollen geschützt (`@PreAuthorize`).
|
||||
* **CircuitBreaker:** Resilience4j sichert DB-Zugriffe ab (`@CircuitBreaker`). Fallback-Methoden ("Degraded Mode") sind
|
||||
aktiv.
|
||||
|
||||
### 🏗️ Infrastructure Upgrade
|
||||
|
||||
* **Valkey Migration:** Erfolgreiche Migration von Redis (proprietär) auf **Valkey 9.0** (Open Source) in
|
||||
`docker-compose` und Environment-Configs.
|
||||
* Images: `valkey/valkey:9.0`
|
||||
* Kompatibilität: Vollständig gegeben (Drop-In Replacement).
|
||||
|
||||
### 🧪 Quality Assurance (Testing)
|
||||
|
||||
* **Integrationstests:** Implementierung von `PingRepositoryTest` mit **Testcontainers** (Postgres).
|
||||
* Prüft Flyway-Migrationen (`V1`, `V2`).
|
||||
* Prüft JPA-Mapping und UUIDv7-Persistenz gegen eine echte Datenbank.
|
||||
* **Test-Isolierung:** Lösung komplexer Spring-Kontext-Probleme (`BeanDefinitionOverrideException`) durch:
|
||||
* Einführung einer isolierten `TestPersistenceConfig` für Repository-Tests.
|
||||
* Nutzung von `@TestConfiguration` in Controller-Tests.
|
||||
* Entfernung des hinderlichen `@Profile("!test")` im `PingRepositoryAdapter`.
|
||||
|
||||
### 📊 Observability
|
||||
|
||||
* **Actuator:** Health, Info, Metrics und Prometheus-Endpunkte sind exponiert.
|
||||
* **Tracing:** Zipkin-Integration vorbereitet via `monitoring-client`.
|
||||
|
||||
## 3. Technische Details & Learnings
|
||||
|
||||
### Problem: Spring Context Pollution
|
||||
|
||||
Während der Implementierung der Integrationstests kam es zu Konflikten zwischen den Bean-Definitionen verschiedener
|
||||
Tests (`BeanDefinitionOverrideException`).
|
||||
**Lösung:**
|
||||
Strikte Trennung der Kontexte. `PingRepositoryTest` lädt nun **nicht** mehr die gesamte `PingServiceApplication`,
|
||||
sondern nur eine minimale `TestPersistenceConfig`, die gezielt nur das Persistence-Layer scannt. Dies beschleunigt die
|
||||
Tests und verhindert Seiteneffekte durch Controller oder Security-Configs.
|
||||
|
||||
### Problem: Profile-Exclusion
|
||||
|
||||
Der `PingRepositoryAdapter` war mit `@Profile("!test")` annotiert. Dies verhinderte, dass Integrationstests (die im
|
||||
`test`-Profil laufen) den echten Adapter nutzen konnten.
|
||||
**Lösung:**
|
||||
Annotation entfernt. In Unit-Tests wird der Adapter ohnehin durch Mocks ersetzt, daher ist die Exclusion unnötig und
|
||||
schädlich für Integrationstests.
|
||||
|
||||
## 4. Nächste Schritte (Handover an Frontend)
|
||||
|
||||
Der Backend-Stack ist stabil. Der Frontend-Expert kann nun die Integration (Phase 2) abschließen:
|
||||
|
||||
1. Login gegen Keycloak.
|
||||
2. Aufruf von `/ping/secure` mit Bearer-Token.
|
||||
3. Test des Delta-Syncs (`/ping/sync`).
|
||||
|
||||
---
|
||||
*Gez. Senior Backend Developer*
|
||||
@@ -0,0 +1,76 @@
|
||||
---
|
||||
type: Report
|
||||
status: ACTIVE
|
||||
owner: Frontend Expert
|
||||
title: Frontend Cleanup & Architecture Status Report
|
||||
date: 2026-02-01
|
||||
author: Frontend Expert & Curator
|
||||
tags: [frontend, architecture, cleanup, kmp, compose]
|
||||
---
|
||||
|
||||
# 🧹 Frontend Cleanup & Architecture Status Report
|
||||
|
||||
## 1. Executive Summary
|
||||
|
||||
Dieses Dokument fasst die umfangreichen Aufräum- und Refactoring-Arbeiten am Frontend ("Meldestelle Portal") zusammen.
|
||||
Ziel war es, technischen Ballast ("Dead Code") zu entfernen, die Architektur zu vereinheitlichen (MVVM + Clean
|
||||
Architecture) und die Kompilierbarkeit über alle Plattformen (JVM/Desktop & JS/Web) sicherzustellen.
|
||||
|
||||
**Ergebnis:** Der Build ist erfolgreich (`BUILD SUCCESSFUL`). Das Frontend ist nun schlank, wartbar und bereit für die
|
||||
Feature-Entwicklung.
|
||||
|
||||
## 2. Durchgeführte Maßnahmen
|
||||
|
||||
### 2.1. Entfernung von "Dead Code"
|
||||
|
||||
* **`frontend/shared` gelöscht:** Dieses Modul enthielt einen kompletten, ungenutzten Redux-Stack (`AppStore`,
|
||||
`AppAction`, etc.), der im Widerspruch zur genutzten MVVM-Architektur stand.
|
||||
* **Legacy-Komponenten entfernt:** Veraltete UI-Komponenten (z.B. `NotificationCard.kt`) und doppelte
|
||||
Navigations-Konzepte wurden bereinigt.
|
||||
|
||||
### 2.2. Architektur-Konsolidierung
|
||||
|
||||
* **MVVM als Standard:** Die Anwendung folgt nun strikt dem MVVM-Muster mit Kotlin Coroutines (`StateFlow`) und Koin für
|
||||
Dependency Injection.
|
||||
* **Clean Architecture:** Das `ping-feature` dient als Referenz-Implementierung mit klarer Trennung von `Presentation`,
|
||||
`Domain` und `Data` Layer.
|
||||
* **Navigation:** Zentralisierung der Navigation auf `AppScreen` (Sealed Class) im Core-Modul.
|
||||
|
||||
### 2.3. Build & Plattform-Support
|
||||
|
||||
* **Koin-Initialisierung:** Korrektur der Koin-Start-Logik für JVM (`startKoin` statt `initKoin`) und JS (`startKoin` im
|
||||
`main.kt`).
|
||||
* **Gradle-Konfiguration:** Bereinigung der `build.gradle.kts` Dateien und Entfernung von Abhängigkeiten zu gelöschten
|
||||
Modulen.
|
||||
* **Web-Support:** Sicherstellung, dass die Web-Version (Kotlin/JS) fehlerfrei baut und die Datenbank (SQLDelight Wasm)
|
||||
korrekt initialisiert.
|
||||
|
||||
## 3. Modul-Status (Ist-Zustand)
|
||||
|
||||
| Modul | Status | Beschreibung |
|
||||
|:-------------------------|:-------|:-----------------------------------------------------------------------|
|
||||
| **`core/navigation`** | ✅ Grün | Zentrale Routen (`AppScreen`, `Routes`), DeepLink-Handling. Sauber. |
|
||||
| **`core/design-system`** | ✅ Grün | UI-Komponenten (`AppTheme`, `Buttons`, `Inputs`). Modern (Material 3). |
|
||||
| **`core/auth`** | ✅ Grün | Login-Logik, Token-Manager, API-Client. Funktional. |
|
||||
| **`core/network`** | ✅ Grün | Zentraler `HttpClient` mit Auth-Interceptor. |
|
||||
| **`core/sync`** | ✅ Grün | Generischer `SyncManager` für Offline-First. |
|
||||
| **`core/local-db`** | ✅ Grün | SQLDelight Setup für JVM & Web. |
|
||||
| **`features/ping`** | ✅ Grün | **Blueprint-Feature**. Zeigt Best Practices (Sync, UI, DI). |
|
||||
| **`shells/portal`** | ✅ Grün | Einstiegspunkt (`MainApp`). Verbindet alle Module. |
|
||||
|
||||
## 4. Offene Punkte & Nächste Schritte
|
||||
|
||||
Obwohl der technische Zustand nun exzellent ist, gibt es logische nächste Schritte für die Produktentwicklung:
|
||||
|
||||
1. **Feature-Rollout:** Implementierung des `members-feature` (Mitglieder) basierend auf dem `ping-feature` Blueprint.
|
||||
2. **Testing:** Etablierung von Unit-Tests für die Core-Logik (Auth, Sync) und UI-Tests für kritische Flows.
|
||||
3. **Backend-Alignment:** Sicherstellung, dass die Backend-Services (Registry) die erwarteten Sync-Endpunkte
|
||||
bereitstellen.
|
||||
|
||||
## 5. Fazit
|
||||
|
||||
Das Frontend-Fundament ist stabil. Die "technischen Schulden" aus der Experimentierphase (Redux vs. MVVM) sind getilgt.
|
||||
Das Team kann sich nun voll auf die Implementierung der fachlichen Anforderungen konzentrieren.
|
||||
|
||||
---
|
||||
*Gez. Frontend Expert & Curator*
|
||||
@@ -0,0 +1,45 @@
|
||||
---
|
||||
type: Report
|
||||
status: ACTIVE
|
||||
owner: Curator
|
||||
date: 2026-02-01
|
||||
author: Curator
|
||||
---
|
||||
|
||||
# Report: Fix Sync Type Mismatch (String vs Long)
|
||||
|
||||
## 1. Problembeschreibung
|
||||
|
||||
Es wurde eine kritische Inkonsistenz im Delta-Sync-Mechanismus zwischen Frontend und Backend festgestellt.
|
||||
|
||||
* **Frontend:** Der generische `SyncManager` nutzte einen String-Cursor (UUIDv7), was zu einem Typ-Fehler führte.
|
||||
* **Backend:** Der `PingController` erwartete strikt einen `Long` (Timestamp) für den Parameter `lastSyncTimestamp`.
|
||||
|
||||
## 2. Durchgeführte Maßnahmen
|
||||
|
||||
### 2.1 Backend (`ping-service`)
|
||||
|
||||
* **Parameter-Umbenennung:** Der Parameter im `PingController` wurde von `lastSyncTimestamp` zu `since` umbenannt, um
|
||||
der Konvention des Frontend-SyncManagers zu entsprechen.
|
||||
* **Tests:** Unit- und Integrationstests (`PingControllerTest`) wurden aktualisiert.
|
||||
|
||||
### 2.2 Frontend (`meldestelle-portal`)
|
||||
|
||||
* **Repository-Anpassung:** `PingEventRepositoryImpl` holt nun explizit den `last_modified` Timestamp aus der
|
||||
Datenbank (via neuer SQL-Query `selectLatestPingEventTimestamp`).
|
||||
* **Typ-Konvertierung:** Der Timestamp wird als String an den `SyncManager` übergeben, der ihn als URL-Parameter
|
||||
anhängt. Spring Boot konvertiert diesen String automatisch zurück in einen `Long`.
|
||||
|
||||
### 2.3 Contracts (`ping-api`)
|
||||
|
||||
* Das Interface `PingApi` wurde aktualisiert: `syncPings(since: Long)`.
|
||||
|
||||
## 3. Ergebnis
|
||||
|
||||
* Die Typ-Sicherheit ist hergestellt.
|
||||
* Tests im Backend laufen erfolgreich durch.
|
||||
* Der Sync-Mechanismus ist nun robust und bereit für den produktiven Einsatz.
|
||||
|
||||
## 4. Status
|
||||
|
||||
✅ **RESOLVED**
|
||||
@@ -0,0 +1,65 @@
|
||||
---
|
||||
type: Report
|
||||
status: ARCHIVED
|
||||
author: Senior Backend Developer
|
||||
date: 2026-01-17
|
||||
context: Phase 3 - Sync Implementation
|
||||
---
|
||||
|
||||
# Backend Status Report: Phase 3 (Sync) abgeschlossen
|
||||
|
||||
**ARCHIVED:** This report reflects a past state. Please refer to `2026-01-23_Weekend_Status_Report.md` for the current
|
||||
status.
|
||||
|
||||
---
|
||||
|
||||
## 1. Zusammenfassung
|
||||
|
||||
Die Phase 3 der "Operation Tracer Bullet" wurde erfolgreich abgeschlossen. Der `PingService` wurde um
|
||||
Delta-Sync-Funktionalität erweitert, um Offline-First-Clients effizient zu unterstützen.
|
||||
|
||||
**Wichtigste Errungenschaften:**
|
||||
|
||||
* **Delta-Sync API:** Implementierung von `/ping/sync` basierend auf Zeitstempeln.
|
||||
* **Contract-Update:** Synchronisierung der API-Definitionen zwischen Backend und Frontend (`:contracts:ping-api`).
|
||||
* **Testing:** Vollständige Testabdeckung für die neuen Sync-Endpunkte.
|
||||
|
||||
---
|
||||
|
||||
## 2. Technische Details
|
||||
|
||||
### A. Sync-Strategie
|
||||
|
||||
* **Mechanismus:** Zeitstempel-basierter Delta-Sync.
|
||||
* **API:** `GET /ping/sync?lastSyncTimestamp={epochMillis}`
|
||||
* **Response:** Liste von `PingEvent` (ID, Message, LastModified).
|
||||
* **Vorteil:** Clients laden nur geänderte Daten, was Bandbreite spart und Offline-Fähigkeit unterstützt.
|
||||
|
||||
### B. Implementierung
|
||||
|
||||
* **Domain:** Erweiterung des `PingUseCase` um `getPingsSince(timestamp: Long)`.
|
||||
* **Persistence:** Effiziente JPA-Query `findByCreatedAtAfter` auf dem `timestamp`-Index.
|
||||
* **Security:** Der Sync-Endpunkt ist aktuell `public` (analog zu anderen Ping-Endpunkten), kann aber bei Bedarf
|
||||
geschützt werden.
|
||||
|
||||
### C. Frontend-Kompatibilität
|
||||
|
||||
* Die Frontend-Clients (`PingApiClient`, `PingApiKoinClient`) wurden aktualisiert, um den neuen Endpunkt zu
|
||||
unterstützen.
|
||||
* Test-Doubles im Frontend wurden angepasst, um die Build-Integrität zu wahren.
|
||||
|
||||
---
|
||||
|
||||
## 3. Offene Punkte & Nächste Schritte
|
||||
|
||||
* **Frontend Integration:** Der Frontend-Expert muss nun die Logik implementieren, um den `lastSyncTimestamp` lokal zu
|
||||
speichern und den Sync-Prozess zu steuern.
|
||||
* **Konfliktlösung:** Aktuell ist der Sync unidirektional (Server -> Client). Für bidirektionalen Sync (Client ->
|
||||
Server) müssen noch Strategien (z.B. "Last Write Wins") definiert werden.
|
||||
|
||||
---
|
||||
|
||||
## 4. Fazit
|
||||
|
||||
Das Backend ist bereit für Offline-First-Szenarien. Die Delta-Sync-Schnittstelle ist performant und einfach zu
|
||||
konsumieren.
|
||||
+16
-10
@@ -8,13 +8,15 @@ context: Phase 1-3 (Backend Ready)
|
||||
|
||||
# Infrastructure Status Report: "Tracer Bullet" Readiness
|
||||
|
||||
**ARCHIVED:** This report reflects a past state. Please refer to `2026-01-23_Weekend_Status_Report.md` for the current status.
|
||||
**ARCHIVED:** This report reflects a past state. Please refer to `2026-01-23_Weekend_Status_Report.md` for the current
|
||||
status.
|
||||
|
||||
---
|
||||
|
||||
**Datum:** 20. Jänner 2026
|
||||
**Autor:** DevOps & Infrastructure Engineer (Updated by Backend Developer)
|
||||
**Ziel:** Bestätigung der Einsatzbereitschaft der lokalen Entwicklungsumgebung für Phase 1 (Backend Hardening) und Phase 3 (Sync).
|
||||
**Ziel:** Bestätigung der Einsatzbereitschaft der lokalen Entwicklungsumgebung für Phase 1 (Backend Hardening) und Phase
|
||||
3 (Sync).
|
||||
|
||||
## 1. Executive Summary
|
||||
|
||||
@@ -36,23 +38,27 @@ Die Integrationstests des `ping-service` gegen die Docker-Umgebung waren erfolgr
|
||||
## 3. Durchgeführte Maßnahmen (DevOps)
|
||||
|
||||
### 3.1. Keycloak Stabilisierung
|
||||
* Umstellung auf offizielles Image `quay.io/keycloak/keycloak:26.4` (start-dev).
|
||||
* Realm-Import via `--import-realm` erfolgreich.
|
||||
|
||||
* Umstellung auf offizielles Image `quay.io/keycloak/keycloak:26.4` (start-dev).
|
||||
* Realm-Import via `--import-realm` erfolgreich.
|
||||
|
||||
### 3.2. Datenbank Initialisierung
|
||||
* Init-Skripte gehärtet.
|
||||
* Sauberer State durch Reset garantiert.
|
||||
|
||||
* Init-Skripte gehärtet.
|
||||
* Sauberer State durch Reset garantiert.
|
||||
|
||||
### 3.3. Konfigurations-Bereinigung
|
||||
* `base-application.yaml` bereinigt und Flyway aktiviert.
|
||||
|
||||
* `base-application.yaml` bereinigt und Flyway aktiviert.
|
||||
|
||||
## 4. Backend Feedback (Phase 1 & 3 Abschluss)
|
||||
|
||||
Der **Senior Backend Developer** bestätigt:
|
||||
|
||||
1. **Connectivity:** Der `ping-service` verbindet sich erfolgreich mit Postgres, Keycloak und Consul.
|
||||
2. **Security:** Die Token-Validierung (Issuer: `http://keycloak:8080/...`) funktioniert im Docker-Netzwerk einwandfrei.
|
||||
3. **Sync:** Die Performance der DB für den Delta-Sync (`/ping/sync`) ist auch bei lokalen Tests sehr gut (Index-Nutzung bestätigt).
|
||||
1. **Connectivity:** Der `ping-service` verbindet sich erfolgreich mit Postgres, Keycloak und Consul.
|
||||
2. **Security:** Die Token-Validierung (Issuer: `http://keycloak:8080/...`) funktioniert im Docker-Netzwerk einwandfrei.
|
||||
3. **Sync:** Die Performance der DB für den Delta-Sync (`/ping/sync`) ist auch bei lokalen Tests sehr gut (Index-Nutzung
|
||||
bestätigt).
|
||||
|
||||
**Status:** Der `ping-service` ist vollständig implementiert (inkl. Hardening & Sync) und bereit für das Frontend.
|
||||
|
||||
+16
-10
@@ -8,7 +8,8 @@ tags: [backend, ping-service, task]
|
||||
|
||||
# Arbeitsauftrag: Implementierung des `ping-service` (Tracer Bullet)
|
||||
|
||||
**ARCHIVED:** This is the original task description. The implementation has evolved. Please refer to `docs/05_Backend/Services/PingService_Reference.md`.
|
||||
**ARCHIVED:** This is the original task description. The implementation has evolved. Please refer to
|
||||
`docs/05_Backend/Services/PingService_Reference.md`.
|
||||
|
||||
---
|
||||
|
||||
@@ -58,6 +59,7 @@ JVM-spezifischen Abhängigkeiten** enthalten, um die KMP-Kompatibilität für da
|
||||
```text
|
||||
PingResponse.kt
|
||||
```
|
||||
|
||||
```text
|
||||
package de.meldestelle.api.ping
|
||||
|
||||
@@ -71,12 +73,13 @@ JVM-spezifischen Abhängigkeiten** enthalten, um die KMP-Kompatibilität für da
|
||||
```
|
||||
|
||||
3. Service-Implementierung in :ping-service
|
||||
|
||||
|
||||
Implementiere die Spring Boot Anwendung.
|
||||
|
||||
- **`PingController.kt`:**
|
||||
- **`GET /api/ping`:** Ein öffentlicher Endpunkt, der eine `PingResponse("Pong", "anonymous")` zurückgibt.
|
||||
- **`GET /api/ping/secure`:** Ein durch Spring Security geschützter Endpunkt. Er soll den `preferred_username` aus dem `Jwt` Principal extrahieren und in der `PingResponse` zurückgeben.
|
||||
- **`GET /api/ping`:** Ein öffentlicher Endpunkt, der eine `PingResponse("Pong", "anonymous")` zurückgibt.
|
||||
- **`GET /api/ping/secure`:** Ein durch Spring Security geschützter Endpunkt. Er soll den `preferred_username` aus dem
|
||||
`Jwt` Principal extrahieren und in der `PingResponse` zurückgeben.
|
||||
|
||||
Hier ist ein Implementierungsvorschlag für den Controller:
|
||||
|
||||
@@ -108,7 +111,7 @@ Erstelle die `application.yml` für den Service. Sie muss die Anwendung für uns
|
||||
- **Service Discovery:** Registrierung bei Consul.
|
||||
- **Security:** Konfiguration als Resource Server, der JWTs vom `issuer-uri` unseres Keycloak-Containers validiert.
|
||||
- **Observability:** Actuator-Endpunkte (`health`, `info`, `prometheus`) freigeben und Tracing aktivieren.
|
||||
|
||||
|
||||
```yaml
|
||||
# in backend/services/ping/ping-service/src/main/resources/application.yml
|
||||
|
||||
@@ -150,7 +153,7 @@ Erstelle die `application.yml` für den Service. Sie muss die Anwendung für uns
|
||||
pattern:
|
||||
level: "%5p [${spring.application.name:},%X{traceId:-},%X{spanId:-}]"
|
||||
```
|
||||
|
||||
|
||||
5. **Build-Konfiguration(`build.gradle.kts`)
|
||||
|
||||
Achte auf die korrekte und saubere Definition der Abhängigkeiten.
|
||||
@@ -172,7 +175,7 @@ Achte auf die korrekte und saubere Definition der Abhängigkeiten.
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
|
||||
- `ping-service/build.gradle.kts`
|
||||
```text
|
||||
plugins {
|
||||
@@ -202,14 +205,17 @@ Achte auf die korrekte und saubere Definition der Abhängigkeiten.
|
||||
testImplementation(libs.bundles.test.spring)
|
||||
}
|
||||
```
|
||||
|
||||
|
||||
## Definition of Done:
|
||||
|
||||
Der Auftrag gilt als erledigt, wenn:
|
||||
|
||||
1. Die Anwendung erfolgreich startet und sich im Consul UI als `UP` registriert.
|
||||
2. Ein `GET`-Request auf `http//localhost:8081/api/ping` (über das Gateway) den Status `200 OK` und die `{"message":"Pong", "principal":"anonymous"}` zurückgibt.
|
||||
2. Ein `GET`-Request auf `http//localhost:8081/api/ping` (über das Gateway) den Status `200 OK` und die
|
||||
`{"message":"Pong", "principal":"anonymous"}` zurückgibt.
|
||||
3. Ein `GET`-Request auf `http//localhost:8081/api/ping/secure` ohne Token den Status `401 Unauthorized` zurückgibt.
|
||||
4. Ein `GET`-Request auf `http//localhost:8081/api/ping/secure` mit einem gültigen Keycloak-Token deb Status `200 OK` und eine Antwort mit dem korrekten Benutzernamen zurückgibt.
|
||||
4. Ein `GET`-Request auf `http//localhost:8081/api/ping/secure` mit einem gültigen Keycloak-Token deb Status `200 OK`
|
||||
und eine Antwort mit dem korrekten Benutzernamen zurückgibt.
|
||||
5. Die Requests in der Zipkin UI als Trace sichtbar sind.
|
||||
|
||||
Bei Fragen zur Konfiguration oder zur Architektur stehe ich dir zur Verfügung.
|
||||
Reference in New Issue
Block a user