031.2 Lektion 1

Es gibt mobile und Desktop-Anwendungen, deren Oberfläche aus HTML gerendert wird und die, wie die Browser, JavaScript als Programmiersprache nutzen. Im Gegensatz zu dem im Browser geladenen Client sind jedoch das HTML und die für das Funktionieren des nativen Clients erforderlichen Komponenten mit der Installation der Anwendung lokal vorhanden. Eine Anwendung, die auf diese Weise funktioniert, ist praktisch identisch mit einer HTML-Seite (beide werden wahrscheinlich sogar von der gleichen Engine gerendert). Es gibt auch Progressive Web Apps (PWA), ein Mechanismus, über den Clients für Webanwendungen für die Offline-Nutzung gepackt werden — beschränkt auf Funktionen, die keine unmittelbare Kommunikation mit dem Server erfordern. In Bezug auf die Möglichkeiten der Anwendung gibt es keinen Unterschied zwischen der Ausführung im Browser und der Kapselung in einer PWA, außer dass der Entwickler bei letzterer mehr Kontrolle darüber hat, was lokal gespeichert wird.

Das Rendern von Schnittstellen aus HTML ist eine so häufig wiederkehrende Tätigkeit, dass die Engine in der Regel eine eigene Softwarekomponente im Betriebssystem ist. Darum kann sie in verschiedene Anwendungen integriert werden, ohne dass sie in das jeweilige Anwendungspaket eingebettet werden muss. In diesem Modell wird auch die Wartung der Rendering Engine an das Betriebssystem delegiert, was Aktualisierungen erleichtert. Es ist sehr wichtig, eine so zentrale Komponente auf dem neuesten Stand zu halten, um mögliche Ausfälle zu vermeiden.

Unabhängig von der Übertragungsmethode laufen in HTML geschriebene Anwendungen auf einer von der Engine geschaffenen Abstraktionsschicht, die als isolierte Ausführungsumgebung fungiert. Insbesondere bei einem Client, der im Browser läuft, stehen der Anwendung nur die vom Browser angebotenen Ressourcen zur Verfügung. Grundlegende Funktionen, wie die Interaktion mit Seitenelementen und die Anforderung von Dateien über HTTP, sind stets verfügbar. Ressourcen, die sensible Informationen enthalten können – wie der Zugriff auf lokale Dateien, den geografischen Standort, die Kamera und das Mikrofon –, erfordern eine ausdrückliche Benutzerautorisierung, bevor die Anwendung sie nutzen kann.

Das zentrale Element eines Webanwendungsclients, der auf dem Server läuft, ist das HTML-Dokument. Neben der strukturierten Darstellung der Oberflächenelemente, die der Browser anzeigt, enthält das HTML-Dokument die Adressen für alle Dateien, die für die korrekte Darstellung und den Betrieb des Clients erforderlich sind.

HTML allein ist nicht vielseitig genug, um komplexere Schnittstellen zu erstellen, und verfügt nicht über allgemeine Programmierfunktionen. Aus diesem Grund wird ein HTML-Dokument, das als Client-Anwendung funktionieren soll, immer von einem oder mehreren CSS- und JavaScript-Sets begleitet.

Das CSS kann als separate Datei oder direkt in der HTML-Datei selbst bereitgestellt werden. Der Hauptzweck von CSS besteht darin, das Aussehen und das Layout der Elemente der HTML-Schnittstelle anzupassen. Obwohl dies nicht unbedingt erforderlich ist, verlangen anspruchsvollere Schnittstellen in der Regel Änderungen der CSS-Eigenschaften der Elemente, um ihren Anforderungen gerecht zu werden.

JavaScript ist eine praktisch unverzichtbare Komponente. In JavaScript geschriebene Prozeduren reagieren auf Ereignisse im Browser. Diese Ereignisse können durch den Benutzer ausgelöst werden oder nicht interaktiv sein. Ohne JavaScript ist ein HTML-Dokument praktisch auf Text und Bilder beschränkt. Die Verwendung von JavaScript in HTML-Dokumenten macht es möglich, die Interaktivität über Hyperlinks und Formulare hinaus zu erweitern, so dass die vom Browser angezeigte Seite wie eine herkömmliche Anwendungsschnittstelle wirkt.

JavaScript ist eine Allzweckprogrammiersprache, die jedoch hauptsächlich in Webanwendungen zum Einsatz kommt. Die Funktionen der Browser-Ausführungsumgebung sind über JavaScript-Schlüsselwörter zugänglich, die in einem Skript verwendet werden, um die gewünschte Operation auszuführen. Der Begriff document beispielsweise wird im JavaScript-Code verwendet, um sich auf das HTML-Dokument zu beziehen, das mit dem JavaScript-Code verbunden ist. Im Kontext der JavaScript-Sprache ist document ein globales Objekt mit Eigenschaften und Methoden, über das man Informationen von jedem Element des HTML-Dokuments erhält. Noch wichtiger ist, dass man über das Objekt document dessen Elemente ändern und sie mit benutzerdefinierten, in JavaScript geschriebenen Aktionen verknüpfen kann.

Eine auf Webtechnologien basierende Client-Anwendung ist plattformunabhängig, da sie auf jedem Gerät mit einem kompatiblen Webbrowser ausgeführt werden kann.

Die Beschränkung auf den Browser bringt jedoch Einschränkungen für Webanwendungen im Vergleich zu nativen Anwendungen mit sich. Die Vermittlung durch den Browser ermöglicht eine Programmierung auf höherer Ebene und erhöht die Sicherheit, aber auch die Verarbeitung und den Speicherverbrauch.

Browser werden permanent weiterentwickelt, um mehr Funktionen bereitzustellen und die Leistung von JavaScript-Anwendungen zu verbessern, aber es gibt inhärente Aspekte bei der Ausführung von Skripten wie JavaScript, die sie im Vergleich zu nativen Programmen für dieselbe Hardware benachteiligen.

Eine Funktion, die die Leistung von im Browser ausgeführten JavaScript-Anwendungen erheblich verbessert, ist WebAssembly. WebAssembly ist eine Art kompiliertes JavaScript, das Quellcode in einer effizienteren, niedrigeren Sprache wie C erzeugt. WebAssembly kann vor allem prozessorintensive Aktivitäten beschleunigen, da es einen Großteil der Übersetzung vermeidet, die der Browser bei der Ausführung eines in herkömmlichem JavaScript geschriebenen Programms vornimmt.

Unabhängig von den Implementierungsdetails der Anwendung müssen der gesamte HTML-Code, CSS-, JavaScript- und Multimediadateien zunächst vom Server abgerufen werden. Der Browser bezieht diese Dateien wie eine Internetseite, d.h. über einer Adresse, auf die er zugreift.

Eine Webseite als Schnittstelle zu einer Webanwendung ist wie ein einfaches HTML-Dokument, fügt aber zusätzliche Interaktionsmöglichkeiten hinzu. Auf herkömmlichen Seiten wird der Benutzer nach dem Anklicken eines Links auf eine andere Seite weitergeleitet. Webanwendungen präsentieren ihre Oberfläche und reagieren auf Benutzerereignisse, ohne neue Seiten im Browserfenster zu laden. Die Änderung dieses Standardverhaltens in HTML-Seiten erfolgt durch JavaScript-Programmierung.

Ein Webmail-Client zeigt zum Beispiel Nachrichten an und wechselt zwischen Nachrichtenordnern, ohne die Seite zu verlassen. Dies ist möglich, weil der Client JavaScript verwendet, um auf Benutzeraktionen zu reagieren und entsprechende Anfragen an den Server zu stellen. Wenn der Benutzer auf den Betreff einer Nachricht im Posteingang klickt, fordert ein mit diesem Ereignis verbundener JavaScript-Code den Inhalt dieser Nachricht vom Server an (über einen entsprechenden API-Aufruf). Sobald der Client die Antwort erhält, zeigt der Browser die Nachricht im entsprechenden Teil der gleichen Seite an. Verschiedene Webmail-Clients haben unterschiedliche Strategien, aber sie nutzen alle dasselbe Prinzip.

Daher muss der Server nicht nur die Dateien, aus denen der Client besteht, dem Browser zur Verfügung stellen, sondern auch in der Lage sein, Anfragen wie die des Webmail-Clients zu bearbeiten, wenn dieser nach dem Inhalt einer bestimmten Nachricht fragt. Für jede Anfrage, die der Client stellen kann, gibt es eine definierte Prozedur auf dem Server, dessen API verschiedene Methoden definieren kann, um festzustellen, auf welche Prozedur sich die Anfrage bezieht. Die gebräuchlichsten Methoden sind:

Je nach Zweck der Anfrage und anderen vom Entwickler berücksichtigten Kriterien kann eine Methode besser geeignet sein als eine andere. In der Regel setzen Webanwendungen auf eine Kombination von Methoden, die jeweils für einen bestimmten Zweck geeignet sind.

Das Representational State Transfer (REST) Paradigma ist für die Kommunikation in Webanwendungen weit verbreitet, da es auf den in HTTP verfügbaren grundlegenden Methoden basiert. Der Header einer HTTP-Anfrage beginnt mit einem Schlüsselwort, das den auszuführenden Grundvorgang definiert: GET, POST, PUT, DELETE etc., begleitet von einer entsprechenden URL, auf die die Aktion angewendet wird. Wenn die Anwendung spezifischere Vorgänge mit einer detaillierteren Beschreibung des angeforderten Vorgangs erfordert, ist das GraphQL-Protokoll möglicherweise die bessere Wahl.

Anwendungen, die auf dem Client/Server-Modell basieren, unterliegen Instabilitäten bei der Kommunikation. Aus diesem Grund muss die Client-Anwendung stets effiziente Datenübertragungsstrategien nutzen, um ihre Konsistenz zu gewährleisten und die Benutzerfreundlichkeit nicht zu beeinträchtigen.

HTTP-Server wie Apache und NGINX erfordern in der Regel spezifische Konfigurationsänderungen, um den Anforderungen der Anwendung gerecht zu werden. Herkömmliche HTTP-Server verknüpfen den in der Anfrage angegebenen Pfad standardmäßig direkt mit einer Datei im lokalen Dateisystem. Wenn der HTTP-Server einer Website seine HTML-Dateien beispielsweise im Verzeichnis /srv/www aufbewahrt, erhält eine Anfrage mit dem Pfad /de/about.html den Inhalt der Datei /srv/www/de/about.html als Antwort, sofern die Datei existiert. Anspruchsvollere Websites und insbesondere Webanwendungen erfordern eine individuelle Behandlung für verschiedene Arten von Anfragen. In diesem Szenario besteht ein Teil der Anwendungsimplementierung darin, die Einstellungen des HTTP-Servers zu ändern, um die Anforderungen der Anwendung zu erfüllen.

Alternativ gibt es Frameworks, die es ermöglichen, die Verwaltung von HTTP-Anfragen und die Implementierung des Anwendungscodes an einem Ort zu integrieren, so dass sich der Entwickler mehr auf den Zweck der Anwendung als auf Plattformdetails konzentrieren kann. In Node.js Express beispielsweise werden das gesamte Request Mapping und die entsprechende Programmierung mit JavaScript realisiert. Da die Programmierung der Clients in der Regel in JavaScript erfolgt, halten es viele Entwickler aus Sicht der Codepflege für eine gute Idee, für Client und Server dieselbe Sprache zu verwenden. Andere Sprachen, die häufig zur Implementierung der Serverseite verwendet werden — entweder in Frameworks oder in traditionellen HTTP-Servern — sind PHP, Python, Ruby, Java und C#.

Es liegt im Ermessen des Entwicklungsteams, wie die vom Client empfangenen oder angeforderten Daten auf dem Server gespeichert werden, aber es gibt allgemeine Richtlinien, die für die meisten Fälle gelten. Es ist zweckmäßig, statische Inhalte — Bilder, JavaScript- und CSS-Code, die sich kurzfristig nicht ändern — als herkömmliche Dateien zu speichern, entweder im eigenen Dateisystem des Servers oder verteilt über ein Content Delivery Network (CDN). Andere Arten von Inhalten, wie E-Mail-Nachrichten in einer Webmail-Anwendung, Produktdetails in einer Shopping-Anwendung und Transaktionsprotokolle, werden besser in einem Datenbankmanagementsystem (DBMS) gespeichert.

Der traditionelle Typ von Datenbankmanagementsystemen ist die relationale Datenbank. In ihr definiert der Anwendungsentwickler Datentabellen und das von jeder Tabelle akzeptierte Eingabeformat. Der Satz von Tabellen in der Datenbank enthält alle dynamischen Daten, die von der Anwendung verarbeitet und erzeugt werden. Eine Shopping-App kann zum Beispiel eine Tabelle haben, die einen Eintrag mit den Details zu jedem Produkt im Laden enthält, und eine Tabelle, die die von einem Benutzer gekauften Artikel aufzeichnet. Die Tabelle der gekauften Artikel enthält Verweise auf Einträge in der Produkttabelle, wodurch Beziehungen zwischen den Tabellen entstehen. Dieser Ansatz kann die Speicherung und den Zugriff auf die Daten optimieren und ermöglicht Abfragen in kombinierten Tabellen mit der vom Datenbankmanagementsystem verwendeten Sprache. Die beliebteste relationale Datenbanksprache ist die Structured Query Language (SQL, ausgesprochen: “sequel”), die von den Open-Source-Datenbanken SQLite, MySQL, MariaDB und PostgreSQL verwendet wird.

Eine Alternative zu relationalen Datenbanken ist eine Form der Datenbank, die keine starre Struktur für die Daten erfordert. Diese Datenbanken werden nicht-relationale Datenbanken oder einfach NoSQL genannt. Obwohl sie einige ähnliche Funktionen wie relationale Datenbanken aufweisen können, liegt der Schwerpunkt auf einer höheren Flexibilität bei der Speicherung und dem Zugriff auf gespeicherte Daten, wobei die Aufgabe der Datenverarbeitung der Anwendung selbst obliegt. MongoDB, CouchDB und Redis sind gängige nicht-relationale Datenbankmanagementsysteme.