Distributed Weather Dashboard (DWD)

Ein verteiltes System zur Abfrage und Aggregation von Wetterdaten aus mehreren Providern.
Das System besteht aus mehreren Komponenten und kommuniziert intern über ein einfaches RPC-Protokoll (JSON newline-delimited über TCP). Extern wird über HTTP eine kleine UI bereitgestellt.

---

Architekturüberblick

Services / Komponenten

• View

  • HTTP Frontend (HTML, CSS, JS, CSV)
  • [RPC] Application-Stub auf Serverseite für Callbacks (Controller --> View)
  • [RPC] Application-Stub auf Clientseite für Weiterleitung von Anfragen (View --> Controller)
  • [HTTP] Application-Stub auf Serverseite für eingehende HTTP-Requests

• Controller

  • Orchestriert einen Request: Timezone + Local Date --> Provider-Abfragen --> Aggregation --> Callback zur View
  • [RPC] Application-Stub auf Serverseite für Callbacks (WDP/Aggregator --> Controller)
  • [RPC] Application-Stub auf Clientseite für Messages an WDP/Aggregator (Controller --> WDP/Aggregator)

• WDP (Weather Data Provider)

  • Holt Wetterdaten von externen APIs (Open-Meteo / BrightSky / WeatherAPI.com)
  • Lokaler Cache (TTL) pro Pod
  • [RPC] Application-Stub auf Serverseite für eingehende Messages (Controller --> WDP)
  • [RPC] Application-Stub auf Clientseite für Callbacks (WDP --> Controller)
  • [HTTP] Application-Stub auf Clientseite für ausgehende HTTP-Requests

• Aggregator

  • Aggregiert die Provider-Ergebnisse (Mittelwert)
  • [RPC] Application-Stub auf Serverseite für eingehende Messages (Controller --> Aggregator)
  • [RPC] Application-Stub auf Clientseite für Callbacks (Aggregator --> Controller)

• Nginx

  • Reverse Proxy im Cluster
  • Entry-Point für HTTP (Weiterleitung an view-http)

Request Flow

Browser --> nginx --> view --> controller --> wdp (3 Provider) --> controller --> aggregator --> controller --> view --> nginx --> Browser

---

Warum funktionieren contracts/ und middleware/ in allen Pods?
Weil aktuell alle Services aus demselben Docker Image starten. Das Image enthält den kompletten src/ Ordner und die entrypoint.sh, die je nach SERVICE die passende Main startet.

---

Lokale Ausführung (ohne Kubernetes)

Voraussetzungen

• Python 3.12
• pip install -r requirements.txt
• optional: curl

Start (Local Multi-Process)

Es gibt ein lokales Startscript (local_main.sh), das alle Prozesse startet (View, Controller, Aggregator, 3× WDP) und Logs nach .logs/ schreibt.

chmod +x local_main.sh
./local_main.sh