Eine Web-App ist ja schön und gut, aber solange sie nur auf unserem lokalen Computer ausgeführt wird, nur beschränkt nützlich. Wir möchten die App auf einem Server im Netz laufen lassen und für alle Nutzenden zugänglich machen.

Ziele:

• Verfügbarkeit: App weltweit und öffentlich verfügbar machen.
• Skalierung: Tausende von gleichzeitigen Spielen ermöglichen.

Falls uns das gelingt, könnten wir darüber nachdenken, ob wir unser Spiel monetarisieren können - also Geld dafür verlangen oder Werbung schalten und stinkreich werden :).

Die Computer, die wir für die Entwicklung verwenden, sind typischerweise nicht frei im Internet erreichbar, da eine Firewall den Zugang von aussen unterbindet. Zudem sind die Geräte oft ausgeschaltet. Und wir möchten auch nicht, dass eine allfällige Sicherheitslücke in unserem Servercode dazu führen könnte, dass unser Gerät kompromittiert wird.

Der Code soll also in einer sogenannten Sandbox (ein Sandkasten, in dem der Code spielen kann, ohne dass etwas Schlimmes passiert) ausgeführt werden. Dieses Hosting wird von vielen Anbietern als Dienstleistung ermöglicht und ist typischerweise kostenpflichtig.

Möglichkeiten:

• Virtual Private Server: einen Server mieten und den Prozess darauf starten
  • Kosten: 12-20 CHF / Monat für einen Einstiegsserver
  • zum Beispiel bei metanet.ch, hetzner.com, oder die grossen Hyperscaler (Google Cloud, Microsoft Azure, Amazon Web Services)
  • du musst selbst das System administrieren (Linuxkenntnisse nötig)
• Cloud Run: ein Anbieter übernimmt die ganze Administration und lässt unseren Code für uns laufen.
  • Kosten: Free Tier reicht völlig aus für uns.
  • zum Beispiel bei render.com

Wir werden die zweite Möglichkeit näher anschauen.

render.com kann unser (public) Repository direkt laufen lassen. Schritte:

• Rufe https://dashboard.render.com/web/new auf.
  • Das erste Mal: Erstelle ein Konto, vorzugsweise via dein Github-Konto.
• Gib die Adresse deines Repositorys an.
• Wähle eine Data-Center-Region - für uns typischerweise Europe-West oder ähnlich.
• Du musst noch mitteilen:
  • wie das Projekt installiert (npm install um alle Abhängigkeiten in node_modules zu installieren)
  • wie das Projekt gestartet wird (node app.js bzw. node index.js)
  • und den Free Tier (Gratismodell) auswählen

Wenn alles klappt, wird das Projekt geklont, installiert, und ist nach ca. 1 Minute auf einem URL wie dem folgenden Verfügbar:

https://ksr-talit-connect4.onrender.com/

Ein Server-Prozess kann nur eine begrenzte Anzahl Spiele ausführen. Für mehr parallele Spiele könnten wir einfach mehrere Prozesse (Instanzen) starten - alle sind unter der gleichen Adresse erreichbar, aber werden im Data Center über verschiedene Mechanismen auf die Instanzen zugeteilt (Load Balancing):

• DNS Load Balancing
  • Der Domainname ksr-talit-connect4.onrender.com wird auf mehr als eine IP-Adresse aufgelöst - der Browser wählt zufällig eine davon aus.
• Server Load Balancing
  • Der vom ersten Request angesprochene Server (Frontend) vermittelt die Anfrage weiter an ein Backend mit genügend Kapazität. Im Datacenter wird die Anfrage also weitergereicht und die Antwort später wieder via Frontend zurück an den Client gesandt.

Mit mehreren Instanzen kann es vorkommen, dass zwei Client-Anfragen an verschiedene Backends gelangen. Da in unserer App aber der ganze Zustand im Speicher der Server-Instanz liegt, fehlt den Backends die gemeinsame Sicht auf das Spiel. Wir müssten also sicherstellen dass alle Anfragen eines Spiels beim gleichen Backend landen. Dies nennt sich Affinität (affinity).

Beim DNS Load Balancing ist das schwierig zu erreichen, weil der Client zufällig die IP-Adresse auswählt. Beim Server Load Balancing hingegen muss das Frontend sich merken, welche Spiele auf welchen Backends laufen, und die Anfragen entsprechend weiterleiten.

Eine einfach Implementierung würden nur den Redirect vom leeren Pfad / auf ein wartendes Spiel (z.B. /0/) so weiterleiten, dass der Client auf einem konkreten Backend landet, z.B. 0.ksr-talit-connect4.onrender.com bis 67.ksr-talit-connect4.onrender.com.

Möchten wir die Spielstände, Highscores etc. langfristig speichern, so dass sie einen Server-Neustart überstehen, müssen alle Server einen gemeinsamen Speicher haben. Mögliche Lösungen wären separate Speichersysteme:

• Key-Value-Stores wie Redis oder Bigtable
• Datenbanken (z.B. MariaDB oder Postgres)
• gemeinsame Dateisysteme