Serverseitige Programmierung — die Sprache, die hinter den Kulissen läuft

Serverseitige Programmierung ist der Code, der auf einem Server statt im Browser der Nutzerin läuft. Hier wohnt die Geschäftslogik: prüfen, ob eine Nutzerin eine Seite sehen darf, Daten in der Datenbank abrufen und speichern und Antworten an das Frontend liefern. Die Verordnung für die Webentwickler-Ausbildung verlangt, dass die Lernenden selbstständig mit serverseitiger Programmierung im Hinblick auf die Erstellung von Weblösungen und die Anbindung an Datenquellen und dahinterliegende Systeme arbeiten können.

Für die serverseitige Entwicklung gibt es viele Sprachen und Umgebungen — zum Beispiel JavaScript in einer Server-Umgebung, PHP, Python, Java und C#. Sie unterscheiden sich in Syntax und Ökosystem, lösen aber im Wesentlichen dieselben Grundaufgaben: eine Anfrage entgegennehmen, mit einer Datenbank sprechen, Geschäftsregeln anwenden und eine Antwort zurücksenden. Wer die Prinzipien in einer Sprache verstanden hat, kann sich weit leichter in eine andere einarbeiten, wenn der Arbeitsplatz das verlangt.

HTTP, das Protokoll hinter praktisch dem gesamten Webverkehr, ist zustandslos: Der Server merkt sich grundsätzlich nichts von einer Anfrage zur nächsten. Ohne etwas Zusätzliches wüsste ein Server deshalb nicht, ob zwei Anfragen vom selben eingeloggten Benutzer kommen. Die Lösung ist, den Server etwas ausstellen zu lassen, das der Browser jedes Mal zurückschickt — typischerweise ein Session-Cookie oder ein Token —, das der Server nachschlagen und wiedererkennen kann. So bleibt ein Benutzer 'eingeloggt', obwohl jede einzelne HTTP-Anfrage in Wirklichkeit für sich steht.

• 01Session: Der Server speichert den Zustand und gibt dem Client nur eine Referenznummer
• 02Token (z. B. ein signierter Zugangsschlüssel): Der Zustand liegt im Token selbst, das der Server ohne Nachschlagen verifizieren kann
• 03Beides muss davor geschützt werden, gestohlen oder erraten zu werden, und muss ablaufen können

Ein Server muss oft Geheimnisse kennen: das Passwort zur Datenbank, Schlüssel zu externen Diensten, den Wert, mit dem Sessions signiert werden. Sie gehören niemals direkt in den Quellcode oder in die Versionsverwaltung, wo sie von allen mit Zugriff auf das Repository gelesen werden können. Stattdessen werden sie als Umgebungsvariablen auf dem Server gesetzt, auf dem der Code läuft, außerhalb dessen, was nach Git committet wird — dieselbe Denkweise, die der Artikel über DSGVO und Web-Sicherheit betont.

Die Verordnung verlangt außerdem Kenntnisse über Webserver, einschließlich Leistung und Funktionalität. Ein Webserver muss viele gleichzeitige Anfragen bewältigen können, ohne in die Knie zu gehen. Was die Leistung typischerweise bestimmt, ist, wie schnell jede Anfrage beantwortet wird (etwa wie effizient die Datenbankabfragen sind), ob Antworten, die sich selten ändern, zwischengespeichert statt jedes Mal neu berechnet werden, und ob der Server skalieren kann, indem bei steigender Last mehrere Instanzen parallel laufen.

Serverseitiger Code ist nicht fertig, bevor er tatsächlich irgendwo läuft, wo die Nutzer ihn erreichen. Das erfordert, dass der Code gepackt, mit den richtigen Umgebungsvariablen eingerichtet und überwacht wird, damit Fehler entdeckt werden, bevor die Nutzer sie selbst finden — das Thema, mit dem der nächste Artikel über Deployment und Betrieb weitermacht.

“Das Frontend ist das, was der Benutzer sieht. Das Backend ist das, was entscheidet, ob das, was der Benutzer sieht, überhaupt wahr und sicher ist.”

— Gängige Faustregel in der Webentwicklung