# Distributed Systems - Challenge Task FS 2025

**Projekt:** Eventkalender "WasLauft"

**Team:**
- Jannis Tschan
- Nina Grässli
- Vanesa Alves

## Ziel dieses Projektes

Dieses Projekt ist Teil der Distributed Systems Challenge Task FS 2025. Ziel ist es, ein verteiltes System mit folgenden Komponenten zu entwerfen und umzusetzen:

1. Ein einfaches Frontend (Blazor WebAssembly), das **Server-Sent Events (SSE)** unterstützt. 
2. Ein Load Balancer (Traefik), der **Lastverteilung** und **Fehlertoleranz** zwischen **zwei Instanzen des Backend-Dienstes** übernimmt. 
3. Ein Backend-Dienst (ASP.NET Core), der **Server-Sent Events** an das Frontend sendet. 
4. Eine persistente Datenbank (PostgreSQL) zur Datenspeicherung. 
5. Dockerisierte Bereitstellung aller Komponenten.

## Tech-Stack

| Komponente    | Technologie   |
|-              |-              |
| Frontend      | Blazor WebAssembly (WASM) |
| Backend       | ASP.NET Core mit SSE |
| Datenbank     | PostgreSQL (persistente Speicherung) |
| Load Balancer | Traefik       |
| Containerisierung | Docker mit Docker Compose für Deployment|

### Frontend und Backend

Blazor bietet zwei Hosting-Modelle: 
 - Blazor WebAssembly (WASM)
 - Blazor Server

Beide nutzen C# und .NET für Webanwendungen, unterscheiden sich aber in der Architektur, Performance und Datenverarbeitung.

| Blazor WebAssembly (WASM) | Blazor Server |
|-                          |-              |
| Client-Seitiger Workload (hält Serverlast gering) | Server-Seitiger Workload (sorgt für schnellere Ladezeiten) |
| Kommunikation mit dem Server erfolgt über server-sent events (SSE). Beispiele: Web-APIs wie REST oder gRPC. | Nutzt automatisch eine SignalR WebSocket-Verbindung für die Kommunikation. |
| Gut für skalierbare Lösungen | Schnelle Entwicklung ohne API-Bau |

Nachteile Blazor Server:
- Höhere Serverlast: Alle Benutzerinteraktionen müssen über SignalR zum Server geschickt werden -> nicht effizient für viele Nutzer.
- Abhängigkeit vom Backend: Wenn eine Backend-Instanz ausfällt, verliert der Client die Verbindung und muss neu laden.
- Komplexere Failover-Strategie: Blazor Server benötigt eine persistente SignalR-Verbindung, was mit Load Balancing schwieriger ist.

**=> Aus diesen Gründen wird für dieses Projekt Blazor WebAssembly gewählt.**

### Datenbank

**Eigenschaften PostgreSQL:**

- Komplexer
- Leistung bei mehreren Benutzern
- Erweiterte Features (komplexe Abfragen, Stored Procedures, Trigger, usw.)
- Datenintegrität
- Skalierbarkeit

**Alternative:** SQLite, ist aber nicht empfohlen, da mehrere Benutzer die Anwendung nutzen und SQLite dafür nicht optlimal ist.

### Load Balancer

**Anforderungen an Load Balancer für Blazor WebAssembly:**
- HTTP/HTTPS Unterstützung
- Caching für statische Inhalte
- SSL/TLS-Termination
- Automatisches Failover
- Lastverteilung

#### Vorteile der Load Balancer

| Traefik | Nginx |
| - | - |
| - WebSockets und Sticky Sessions sind out-of-the-box integriert | - Hohe Stabilität und Performance |
| - Einfache Konfiguration und gute Performance für Blazor Server | - Effizientes Caching für statische Inhalte |
| - Besser für dynamische Setups mit Docker & Microservices | - Flexibel und anpassbar |
| | - Einfache SSL/TLS-Implementierung |
| | - Grosse Community und gute Dokumentation |

**=> Traeffik wurde für dieses Projekt gewählt, weil es eine schnellere Implementierung bietet als Nginx**

### Traefik Configuration

Traefik wird als Load Balancer in diesem Projekt verwendet und übernimmt folgende Aufgaben:

1. **HTTP-Traffic-Management**: Leitet eingehenden HTTP-Traffic an die entsprechenden Dienste weiter (z. B. Frontend oder Backend).
2. **Traefik-Dashboard**: Bietet ein Dashboard auf Port `80` zur Überwachung und Verwaltung der Routing-Konfiguration.
3. **Dynamische Konfiguration**: Erkennt automatisch die in `docker-compose.yml` definierten Dienste und deren Routen.
   - **Frontend**: Erreichbar über den EntryPoint `/` und leitet Traffic an den `frontend`-Service weiter (erreichbar unter `:8082`).
   - **Backend**: Erreichbar über den EntryPoint `/backend` und leitet Traffic an die beiden Backend-Instanzen (`backend1` und `backend2`) weiter.
4. **Load Balancing**: Verteilt den Traffic gleichmässig zwischen den beiden Backend-Instanzen.
5. **Health Checks**: Überwacht die Verfügbarkeit der Backend-Instanzen und entfernt fehlerhafte Instanzen aus dem Load Balancer.
6. **EntryPoint-Konfiguration**: Verarbeitet Web-Traffic über die folgenden EntryPoints:
   - **web**: Standard-HTTP-Traffic auf Port `8082`.
   - **dashboard**: Traefik-Dashboard auf Port `80`.

## Installation / Startup

### Docker
Die folgenden Befehle starten und beenden die Docker-Container der Applikation.

Um diese Befehle auszuführen, muss zunächst in den Projektordner gewechselt werden, in dem sich die Docker-Compose Datei befindet: `src\WasLauft\docker-compose.yml`.

| Befehl | Beschreibung |
| - | - |
| ```docker-compose down``` | Laufende Container stoppen und entfernen. |
| ```docker-compose up --build``` | Container erstellen und starten. |
| ```docker-compose logs -f``` | Überwachung der Logs, ohne Neustart der Dienste. |
| ```docker-compose stop``` | Container stoppen, ohne sie zu entfernen. |
| ```docker-compose start``` | Container erneut starten. |

**Datenbank-Persistenz**:
Das benannte Volume `pgdata` stellt sicher, dass die PostgreSQL-Datenbankdaten auch nach dem Entfernen der Container erhalten bleiben.

### Traefik-Dashboard
Das Traefik-Dashboard ist unter `http://localhost/dashboard/#/` verfügbar. Hier können die Routen und der Status der Dienste überprüft werden.

### Frontend und Backend
- **Frontend**: Erreichbar unter `http://localhost:8082`.
- **Backend**: API-Endpunkte sind unter `http://localhost:8080` und `http://localhost:8081` verfügbar. Der Traffic wird automatisch zwischen den beiden Backend-Instanzen (`backend1` und `backend2`) verteilt.

### Health Checks
- **Datenbank**: Die PostgreSQL-Datenbank wird regelmässig überprüft, um sicherzustellen, dass sie verfügbar ist, bevor abhängige Dienste starten.
- **Backend**: Die Backend-Instanzen werden durch Traefik überwacht. Traefik ruft den Endpunkt `/api/health_check` auf, um die Verfügbarkeit zu prüfen. Fehlerhafte Instanzen werden automatisch aus dem Load Balancer entfernt, bis sie wieder gesund sind.
