mrcwlnd/timetracker
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
b8b01871ed9b5b2bddb94309e525740e839b1e70
timetracker/wasm.md
T
Wieland, Marc fe294e288a wasm migration plan added
2026-06-08 15:50:42 +02:00

7.4 KiB
Raw Blame History

Blazor WASM Migration – Aufwandsanalyse

Analysiert am 08.06.2026
Aktueller Stack: Blazor Server (.NET 10, InteractiveServer, SQLite, MudBlazor 9.4)

TL;DR

Eine vollständige Migration auf Blazor WebAssembly ist technisch möglich, aber ein erheblicher Umbau. Der Aufwand liegt bei schätzungsweise 3–5 Wochen für einen Entwickler. Der Hauptgrund: Blazor WASM läuft vollständig im Browser – kein direkter DB-Zugriff, keine Cookie-Auth serverseitig, keine gemeinsamen In-Process-Events zwischen Nutzern.

Empfehlung: Hybrid-Modell (Blazor Auto oder WASM + ASP.NET Core API auf demselben Server) ist der pragmatischste Weg.

Was WASM bringt

Vorteil Erklärung
Keine SignalR-Verbindung nötig WASM lädt den Code einmalig herunter, kein dauerhafter WebSocket
Besser skalierbar Server hält keine Circuits pro User im Speicher
Offline-fähig (theoretisch) Progressive Web App möglich
Geringere Serverauslastung UI-Logik läuft im Browser

Aber Achtung: Der initiale Download ist größer (~10–20 MB .NET Runtime im Browser), erste Ladezeit spürbar langsamer als Blazor Server.

Aktuelle Blocker (nach Schwere)

🔴 KRITISCH – muss komplett umgebaut werden

1. Datenbankzugriff – EF Core / SQLite

Alle drei Services greifen direkt per IDbContextFactory<TimetrackerDbContext> auf die SQLite-DB zu:

  • AuthService → Login, Registrierung, User-CRUD
  • TimetrackerService → Arbeitstage, Pausen, Einstellungen, Urlaub, Überstunden
  • HolidayService → Feiertage speichern/lesen

WASM kann nicht direkt auf eine Datenbank zugreifen. Browser hat keinen Dateisystemzugriff.

→ Lösung: Alle Service-Methoden als REST-API-Endpoints auf dem Server exponieren. WASM-Client ruft diese per HttpClient auf.

Aufwand: ~10–15 Tage (je nach gewähltem API-Stil: Minimal API vs. Controller)

2. Cookie-Authentifizierung

Aktuell läuft der gesamte Auth-Flow serverseitig:

  • POST /auth/login → HttpContext.SignInAsync() → Cookie setzen
  • GET /auth/logout → HttpContext.SignOutAsync()
  • Blazor-Komponenten lesen den Cookie über CascadingAuthenticationState

In WASM gibt es keinen direkten Zugriff auf HttpContext. Die Cookie-Auth muss weiterhin serverseitig verbleiben, aber das Login-Formular muss über die API kommunizieren.

→ Lösung A (einfacher): Cookie-Auth beibehalten, aber Login-Formular als API-Call (kein HTML-Form-Post mehr). WASM erhält Auth-State über einen /auth/me-Endpoint.
→ Lösung B (aufwändiger): JWT-Token-Auth einführen, Token im Browser-Speicher halten.

Empfehlung: Lösung A, da Cookie-Auth bereits implementiert ist und sicherer gegen XSS ist als localStorage-JWTs.

Aufwand: ~3–4 Tage

3. Projektstruktur – neue Build-Konfiguration

Aktuell: 1 Projekt (Microsoft.NET.Sdk.Web), alles in einem.

WASM benötigt mindestens:

  • timetracker.Client – Blazor WASM-Projekt (läuft im Browser)
  • timetracker.Server – ASP.NET Core-Projekt (hostet API + WASM-App)
  • Optional: timetracker.Shared – DTOs/Models geteilt zwischen Client & Server

Alle @inject-Direktiven, die auf Server-Services zeigen, müssen im Client auf HttpClient-basierte Services umgestellt werden.

Aufwand: ~3–4 Tage (Projektaufspaltung, DI-Umverdrahtung)

⚠️ MITTEL – umbaubar, aber aufwändig

4. UserNotificationService (Live-Updates)

Aktuell: Singleton mit C#-Events, der zwischen Blazor Server-Circuits kommuniziert:

  • Admin löscht User → Event feuert → alle aktiven MainLayout-Instanzen reagieren
  • Neuer User registriert → AdminUsers aktualisiert sich live

In WASM gibt es keine gemeinsamen In-Process-Events. Jeder Browser ist isoliert.

→ Lösung: SignalR Hub einführen. Server sendet Push-Nachrichten an alle verbundenen Clients.

[Browser A – Admin]           [Server]            [Browser B – normaler User]
    löscht User C   →   Hub.Clients.All.SendAsync   →   empfängt "UserDeleted(C)"
                                                          → NavigateTo("/auth/logout")

Aufwand: ~2–3 Tage (Hub einrichten, Client-seitig HubConnection einbauen)

5. Formular-basiertes Login/Register

Login und Registrierung verwenden aktuell native HTML-Forms (method="post") die direkt an /auth/login und /auth/register posten. Das funktioniert in WASM nicht mehr sauber, weil WASM SPA-Navigation nutzt.

→ Lösung: Login-Formular auf @code-basierten HttpClient.PostAsync-Call umstellen, Redirect über NavigationManager.

Aufwand: ~1 Tag

6. Docker-Deployment

Aktuell: 1 Container, alles drin.

WASM + API = zwei Artefakte:

  • Die WASM-App sind statische Dateien (HTML/JS/WASM)
  • Die API läuft als ASP.NET Core-Server

→ Lösung A (einfach): Hosted WASM – API-Server liefert auch die WASM-Dateien aus (1 Container, 1 Dockerfile, wie heute)
→ Lösung B (komplex): Getrennte Container (Nginx für WASM, API separat)

Empfehlung: Lösung A (Hosted WASM) – minimaler Deployment-Overhead.

Aufwand: ~0,5 Tage bei Lösung A

✅ KEIN UMBAU NÖTIG

Komponente Warum kein Umbau
MudBlazor 9.4 Vollständig WASM-kompatibel
Alle .razor-Seiten (UI) Markup bleibt identisch, nur @inject ändert sich
Entity Models (User, WorkDay, etc.) Können ins Shared-Projekt verschoben werden
HttpClient für Feiertage (nager.at) Funktioniert in WASM nativ
Business-Logik in Komponenten Bleibt unverändert
CSS / MudBlazor Theme Unverändert

Gesamtaufwand-Schätzung

Aufgabe Geschätzter Aufwand
Projektstruktur aufteilen (Client/Server/Shared) 2–3 Tage
REST-API für TimetrackerService 4–5 Tage
REST-API für AuthService + HolidayService 2–3 Tage
Cookie-Auth auf API-Flow umstellen 2–3 Tage
Client-Services (HttpClient-basiert) erstellen 3–4 Tage
SignalR für Live-Notifications 2–3 Tage
Login/Register-Formulare anpassen 1 Tag
Docker/Deployment anpassen 0,5–1 Tag
Testen & Debugging 2–3 Tage
Gesamt ~18–26 Tage

Empfohlene Alternative: Blazor Auto

.NET 8+ bietet Blazor Auto-Rendermodus: Seiten starten als Server-Rendering, wechseln dann automatisch zu WASM sobald die Runtime heruntergeladen ist. Das gibt sofortige Interaktivität (Server) + langfristig WASM-Performance.

Vorteil: DB-Zugriff und Auth bleiben wie heute, kein API-Layer nötig.
Aufwand: ~3–5 Tage (Projektstruktur, Shared-Projekt, WASM-Client-Projekt anlegen).

Für dieses Projekt sehr empfehlenswert, da:

  1. Minimaler Umbau der bestehenden Logik
  2. Spürbare Performance-Verbesserung nach erstem Laden
  3. Kein SignalR-Umbau notwendig (Server-Circuit bleibt beim ersten Laden aktiv)

Fazit

Option Aufwand Performance-Gewinn Empfehlung
Blazor WASM (pure) ~20–25 Tage Hoch (nach erstem Laden) Nur bei hoher Nutzerzahl sinnvoll
Blazor Auto ~3–5 Tage Mittel-Hoch ✅ Empfohlen
Blazor Server (wie heute) 0 – Gut für kleine Nutzerzahl

Für den aktuellen Use-Case (internes Uni-Tool, überschaubare Nutzerzahl) ist Blazor Auto das beste Kosten-Nutzen-Verhältnis. Eine vollständige WASM-Migration lohnt sich erst, wenn die App deutlich mehr parallele User hat oder offline-Fähigkeit gefordert wird.

Reference in New Issue View Git Blame Copy Permalink