So entsteht diese Website

Diese Website besteht aus statischen Seiten, die bei Änderungen automatisch neu generiert werden. Aus Quellcode, lokalen Zuordnungen und YouTube-Daten entstehen HTML-Seiten, eine Offline-App und maschinenlesbare Inhalte. GitHub Actions übernehmen die Generierung und Veröffentlichung, aber Besucher erhalten die fertigen Dateien über Cloudflare und GitHub Pages.

Animation pausieren

■ DEV · Entwicklung / Zuordnungen
■ ARCHIV · Magazinquellen
■ YT · YouTube / Caches
■ BUILD · gemeinsame Verarbeitung
■ WEB · Besucherzugriff

Simulation im Diagramm

Besucher: Alle 3 Sekunden wird ein Seitenaufruf simuliert. Jeder zweite führt zum Ursprungsserver (Origin) bei GitHub Pages.
Entwicklung: Nach 5 Sekunden wird einmalig ein git push simuliert.
YouTube: Alle 20 Sekunden zeigt ein Beispiel die Aktualisierung – Fetch-Action aktivieren → YouTube abrufen → Cachedateien schreiben.
Darstellung: Boxen werden kurz hervorgehoben, neue Daten erscheinen vorübergehend grün.
Dabei werden keine echten Anfragen gesendet oder Deployments gestartet. Der tatsächliche automatische YouTube-Abruf erfolgt täglich.
Architekturstand: 30.10.2026. Markenicons: Simple Icons (CC0-1.0) (externe Website); Markenrechte bleiben bei den jeweiligen Anbietern.

F1 · Entwicklung und lokale Daten

Manuelle Magazin-Fetches zur Referenzierung von Blätterabend-Videos laufen über dev:fetch:archives, bei Bedarf auch über dev:fetch:gamestar und dev:fetch:amiga-action. Danach werden die Zuordnungen geprüft.
Die lokale Zuordnungsdatenbank besteht aus Dateien. Sie verknüpfen Magazine mit Heften und Spiele mit Playlists. Dafür läuft kein Datenbankserver. Spielezuordnungen werden manuell bestätigt; vorbereitete Spielemetadaten ergänzen den Bestand.
Quellcode und geprüfte Daten gelangen per Commit und git push in den Branch main des Repositorys. Dieser git push startet die Site-Action.

F2 · YouTube und Cache-Aktualisierung

Die im Diagramm als fetch:videos bezeichnete GitHub Action gehört zum Workflow „Update YouTube caches“. Er läuft täglich, nicht über einen YouTube-Webhook. Aktualisierungen in Echtzeit sind nicht garantiert.
fetch:videos erkennt neue öffentliche Video-IDs. fetch:playlists läuft bei neuen Videos, fehlenden Ausgabedateien oder aktivierter Option force_playlists. Der Abruf erfolgt wahlweise über die offizielle API oder anonym ohne API-Schlüssel.
Die Daten werden in cache/youtube-videos.json und cache/youtube-playlists.json gespeichert. Der Bot erstellt nur für geänderte Dateien einen Commit und überträgt ihn per git push. Neue Spiele werden dabei nicht automatisch redaktionell zugeordnet.
Nach erfolgreichem Abschluss startet site:generation über workflow_run, auch wenn sich keine Daten geändert haben.

F3 · Generierung und Veröffentlichung

Die im Diagramm als site:generation bezeichnete GitHub Action gehört zum Workflow „Deploy to GitHub Pages“. Die Generierung läuft mit npm run generate:site. Weitere Auslöser sind ein git push auf main oder ein manueller Workflow-Start.
Der Ablauf ist test → build → deploy. Der Build verwendet denselben Commit, der zuvor getestet wurde. Nach einem Fetch-Lauf wird der aktuelle main-Stand getestet. Fehler verhindern eine neue Veröffentlichung.
Node.js erzeugt drei gleichrangige Ausgaben: site/ (HTML und Assets), app/ (Offline-App) und ai-bot/ (Markdown, llms.txt, API und Katalog). Das Diagramm zeigt logische Zweige, keine drei parallel gestarteten Workflows.
Alle Ausgaben werden in einem docs/-Artefakt gebündelt und auf GitHub Pages veröffentlicht. Sie werden nicht als generierter Git-Commit gespeichert. Die öffentliche Domain ist prettyoldpixel.com.
Der Build liest vorbereitete lokale Daten, ohne YouTube oder Magazinarchive abzurufen. site/ und ai-bot/ sind Diagrammbezeichnungen, keine zusätzlichen öffentlichen Verzeichnisse.
Gerundete Größenordnung des aktuellen Builds: rund 610 HTML-Seiten beziehungsweise 680 Website-Dateien mit Assets, 90 App-Dateien und 620 Agentendateien. Die Mengen ändern sich mit dem Katalog.

F4 · Besucher und Auslieferung

Seitenaufrufe laufen über HTTPS an prettyoldpixel.com, dann über Cloudflare und bei Bedarf weiter zu GitHub Pages. Antworten nehmen den umgekehrten Weg. Cloudflare dient als vorgeschalteter Proxy und als Content Delivery Network (CDN).
Die Animation zeigt abwechselnd eine Antwort aus dem Cloudflare-Cache und einen Abruf beim Ursprungsserver (Origin) von GitHub Pages. Jeder zweite simulierte Aufruf erreicht den Origin. Dieses Verhältnis ist ein Beispiel und keine gemessene Cache-Trefferquote.
Videos bleiben auf YouTube. Erst nach Player-Aktivierung verbindet sich der Browser direkt mit YouTube, nicht über einen Video-Proxy bei GitHub Pages.
Die animierten Pfeile und die grüne „neu“-Markierung veranschaulichen den Ablauf. Sie zeigen keinen Live-Status. Du kannst die Animation pausieren oder reduzierte Bewegung im Betriebssystem aktivieren.