Als Single-Page-Webanwendung (englisch single-page application, kurz SPA) oder Einzelseiten-Webanwendung wird eine Webanwendung bezeichnet, die aus einem einzigen HTML-Dokument besteht und deren Inhalte dynamisch nachgeladen werden. Im Gegensatz dazu bestehen klassische Webanwendungen aus mehreren, untereinander verlinkten HTML-Dokumenten. Hierdurch wird die Grundlage geschaffen, eine Webanwendung in Form einer Rich-Client- bzw. Fat-Client-Verteilung zu entwickeln. Eine verstärkte clientseitige Ausführung der Webanwendung ermöglicht eine Reduzierung der Serverlast sowie die Umsetzung von selbstständigen Webclients, die beispielsweise eine Offline-Unterstützung anbieten.

Ziele und Anforderungen Bearbeiten

 
Skizzierung des Ablaufs einer Single-Page-Webanwendung

Durch die Nutzung einer einzigen Webseite als Fundament für eine vollständige Webanwendung kann die Client-Server-Kommunikation reduziert werden. Die Webseite kann zur Laufzeit der Applikation dynamisch erweitert werden. Auf diese Weise kann auf eine Navigation zwischen verschiedenen Webseiten verzichtet und die Wartezeit reduziert werden. Bei dem sonst üblichen Wechsel von Unterseiten einer Webanwendung im Webbrowser wird sämtliche clientseitige Präsentationslogik beendet und auf der nächsten Webseite neu begonnen. Ein solches Verhalten unterbindet andauernde clientseitige Vorgänge sowie die Nutzung einer durchgängigen WebSocket-Verbindung.

Ein weiteres Merkmal von SPAs wird häufig mit dem Titel „offline-friendly“ bezeichnet. Durch die vollständige Umsetzung der Präsentationsschicht auf dem Client ist es möglich, mithilfe der Web-Storage-Funktion persistente Zwischenspeicher anzulegen. Für den Fall, dass der Nutzdatenserver nicht erreichbar ist, können Daten aus dem Zwischenspeicher verwendet werden. Die Anwendung kann somit weiterhin auf dem Client betrieben werden, ohne dass eine Verbindung zum Server bestehen muss. Der Einsatz einer clientseitigen Persistierung kann über die Bildung von Zwischenspeicher hinausgehen und zu einer verteilten Persistenz führen. In solchen verteilten Datenhaltungen kann jeder Client als einzelner Datenknoten betrachtet werden, welcher bei einer bestehenden Kommunikationsverbindung seinen Datenvorrat mit anderen Teilnehmerknoten synchronisiert. Die Eigenschaft „offline-friendly“ verweist ebenfalls auf die Portierbarkeit von Single-Page-Applikationen auf mobile Endgeräte hin. Sogenannte mobile HTML5-Offline-Apps basieren größtenteils auf der gleichen Infrastruktur wie SPAs.

Bei Single-Page-Webanwendungen findet eine Dezentralisierung statt. Während in bisherigen Vorgehensweisen der Webserver die zentrale Einheit zur Steuerung der Präsentation war, stellt dieser in SPAs nur noch benötigte Daten bereit. Die Webanwendung wird in zwei getrennte Systeme segmentiert. Folgende drei Regeln für die Segmentierung bei Single-Page-Webanwendungen können definiert werden:[1]

  • Der Sitzungszustand wird in der Client-Applikation gespeichert, nicht im Server.
Durch die Realisierung der Webanwendung auf Basis eines einzelnen HTML-Dokuments bleibt der Zustand der Anwendung im Webclient stets erhalten. Das erneute Laden dieses HTML-Dokuments ist mit einem Neustart der Anwendung gleichzusetzen. Hinzu kommt, dass HTTP ein ressourcenorientiertes und zustandsloses Protokoll ist. Die sonst übliche künstliche Emulation von Sitzungszuständen auf Basis von Cookies ist bei Single-Page-Webanwendungen somit nicht mehr nötig. Die Art der Sitzungsverwaltung ist ein klassisches Entwurfsproblem bei verteilten Anwendungen, welches sich stark auf die Skalierbarkeit und Performanz der Anwendung auswirken kann. Durch die clientseitige Sitzungsverwaltung können die serverseitigen Funktionalitäten zustandslos implementiert werden. Das bedeutet, dass bei einer Lastverteilung ein beliebiger Serverknoten antworten kann. Des Weiteren werden serverseitig keine Ressourcen pro aktiver Clientsitzung verbraucht.
  • Der Webclient ist eine unabhängige Einheit und baut auf verschiedenen Services auf.
Dies erlaubt, dass der Webclient selbstständig auf Benutzeraktionen reagieren kann. Auf eine Vielzahl von Client-Server-Roundtrips kann verzichtet werden, wodurch der Datenverkehr reduziert wird, die Anwendung schneller reagiert und die User Experience zunimmt. Des Weiteren kann der Client losgelöst von einem Server entwickelt werden und muss die Services nur einsetzen, wenn diese benötigt werden.
  • Die verwendeten Services treffen keine Annahmen darüber, wie der Webclient die angebotenen Dienste einsetzt.
Die Serverseite kann ebenfalls – losgelöst vom Client – implementiert und getestet werden. Durch diese Entkopplung können die bereitgestellten Dienste ebenfalls in verschiedenen anderen Projekten verwendet werden.

Einsatzszenarien Bearbeiten

Große Benutzerzahlen
Einsatzgebiete mit großen Benutzerzahlen sind das typische Standardszenario für Single-Page-Webanwendungen. Erfolgreiche Projekte wie Facebook, Google Gmail, Google Maps und Twitter haben hierbei Pionierarbeit geleistet. Alle Beispiele sind im B2C-Markt vertreten. Hierbei ist mit großen Benutzeranzahlen zu rechnen. Um die Serverlast zu reduzieren und zeitgleich eine optimale Skalierbarkeit der Anwendung zu realisieren, bietet sich das SPA-Paradigma an. Der Betrieb einer ausschließlich clientseitigen Präsentation und Sitzungsverwaltung entlastet die serverseitige Infrastruktur und erlaubt eine Skalierung ohne verteilte Caches auf der Ebene des Anwendungsservers („Dezentralisierung“).
Offlineszenarien
Die Realisierung von Offlineszenarien ist zwar auf Basis des HTML5 Application Cache auch für klassische Webanwendungen möglich, jedoch erfolgt in einem solchen Szenario lediglich eine clientseitige Speicherung von serverseitig generierten HTML-Dokumenten. Geschäftslogiken können nicht ausgeführt werden. Offlineszenarien auf Basis des SPA-Paradigmas erlauben im Gegensatz dazu die Ausführung von clientseitiger Fachkonzeptlogik in einem Offlineszenario. Begrenzt wird dies im Endeffekt lediglich durch die Verfügbarkeit der benötigten Daten. Zur clientseitigen Datenbereitstellung erlaubt das SPA-Paradigma, die Implementierung von Datenbereitstellungsstrategien, wie Caching, Replikation oder Hoarding. Hierdurch kann ein produktiver Einsatz einer Webanwendung in einem Offlineszenario angeboten werden.
Kleine Projekte
Ein überschaubares Fachkonzept, wie bei Unternehmensauftritten oder „Product-Landing-Pages“, bietet sich für eine Implementierung nach dem SPA-Paradigma an. Aufgrund des kleinen Fachkonzepts hält sich die Menge der Geschäftslogik, welche clientseitig umgesetzt wird, in Grenzen. Das Hauptaugenmerk bei der Implementierung befindet sich auf der Präsentationsschicht. Das SPA-Paradigma kann in diesem Einsatzgebiet eine hohe Interaktivität bieten und erlaubt die Umsetzung einer ansprechenden Bedienoberfläche.
Hohe Interaktivität
Für Anwendungen wie Computerspiele bietet der Webbrowser gerade im 2D-Bereich eine plattformunabhängige Infrastruktur an. In diesem Anwendungsbereich sind eine hohe Interaktivität und kurze Latenzzeiten erforderlich. Die Implementierung solcher Anwendungen wurde in der Vergangenheit bereits als Plug-in unterstützte SPA mit Adobe Flash oder Microsoft Silverlight durchgeführt. Mit dem Einzug von HTML5, Canvas, WebSockets und WebGL stellen RIA/JS-SPAs eine Alternative dar. Die auf JavaScript basierende Umsetzung bietet den Vorteil, dass ausschließlich Webstandards eingesetzt werden, welche ebenfalls auf mobilen Endgeräten zur Verfügung stehen. Auf diese Weise können mit einer Implementierung mehrere Zielsysteme adressiert werden.
Hybride Web-Apps
Das SPA-Paradigma eignet sich für die Einbettung in native mobile Anwendungen. Bei sogenannten hybriden Anwendungen wird ein Webclient über ein Framework, wie Apache Cordova, eingebettet. Die Art und Weise der Implementierung einer solchen Web-App erfolgt clientnah und meist nach dem SPA-Paradigma.

Mögliche JavaScript-Frameworks für SPAs Bearbeiten

Folgende MV*-Frameworks (MV* als Platzhalter für MVC, MVVM, MVP, …) können zur Implementierung eines SPA-Webclients verwendet werden:

Techniken Bearbeiten

Es gibt verschiedene Ansätze, um eine Kommunikation zwischen SPAs und Servern zu ermöglichen. Die unten aufgeführten Beispiele unterscheiden sich vor allem hinsichtlich ihrer Richtung des Datenflussen und in ihrem Verbindungsaufbau:

Siehe auch Bearbeiten

Weblinks Bearbeiten

Einzelnachweise Bearbeiten

  1. Experiences on a Design Approach for Interactive Web Applications. Abgerufen am 28. März 2021.