Die Inhalte der Session habe ich in diesem Beitrag zusammengefasst und dem kritischen Artikel "'Headless Drupal' - The Cake is a Lie" von Sebastian Siemssen gegenübergestellt.

Angular macht Drupal fit für das Web 3.0, das Internet der Dinge

Das Web 1.0 war komplett statisch. Feststehende HMTL-Dokumente wurden auf Servern bereitgestellt und von Browsern abgefragt.

Das Web 2.0 setzte dynamische – z.B. mit PHP erstellte – Webseiten als neuen Standard. Bevor eine Seite an den Client ausgeliefert wird, werden die jeweiligen Daten aus einer Datenbank ausgelesen und die HTML-Seite wird vom programmierten PHP-Code zum Zeitpunkt ihres Aufrufs gebaut und an den Client ausgeliefert. CM-Systeme wie Drupal, Wordpress oder andere erleichtern es den Nutzern, eigene dynamische Websites zu bauen und zu betreiben.

Das Web 3.0 ist das "Internet der Dinge". Es gibt nicht nur Browser, Tablets oder Smartphones. Wir haben es mit Brillen, Wearables oder sogar Kühlschränken zu tun, die über das Internet vernetzt sind und zum Teil gar keinen Browser besitzen. Web-"Seiten" sind nicht mehr allein für Menschen gebaut.

Hieß der Ansatz im späten Web 2.0 noch "mobile first", so heißt er im Web 3.0 "API-first". Die moderne "Website" entwickelt sich zur "Web-Application": Geräte verstehen JSON. Sofern der Client ein Browser für Menschen ist, wird die Website lokal mit Javascript gebaut. Hierfür werden die Templates an den Besucher übermittelt und dort lokal mit Daten aus einem "local storage" gerendert.

Die Applikation und der Webserver haben – außer, dass sie die gleiche API "sprechen" – nichts mehr miteinander gemein. Die Applikation kann beliebig – z.B. in der Cloud – gehostet werden. Der Webserver stellt nur noch einen Hub für die Daten dar.

Headless Drupal

Wenn als Daten-Backend Drupal eingesetzt wird, wird diese Architektur als "Decoupled Drupal" bzw. als "Headless Drupal" bezeichnet.

Mit der neuen REST-Architektur unterstützt der Drupal 8 Core dies bereits von Haus aus. Via REST kann es mit den Clients das Protokoll aushandeln und die Daten im Bedarfsfall als reines JSON zur Verfügung stellen.

Hierfür werden folgende Core-Module benötigt:

  • HAL
  • HTTP Basic authentication
  • RESTful Webservices
  • Serialization

Auf diese Weise wird serverseitig nur der Core und keine weiteren Module benötigt. Um beim Client z.B. eine Google Map darzustellen, muss in der Applikation lediglich die entsprechende Angular-Komponente eingebunden sein bzw. on demand nachgeladen werden. Der Server liefert in diesem Fall nur die Geo-Koordinaten.

Um Web-Applikationen zu bauen, sollte die erste App der API Test sein. APIs lassen sich z.b. mit Supertest gut testen.

Zugriffskontrolle ist ebenfalls möglich, da Drupal 8 die Benutzer-Authentifizierung via REST unterstützt.

Indem das im Browser darzustellende HTML per Javascript vom Client gebaut wird und der Server nur noch die reinen Daten übertragen muss, kann das Frontend enorm schnell sein. Damit die diese Architektur auf den ersten Blick sehr bestechend.

Angular.js versus "Headful Drupal"

Meines Erachtens bleiben dabei jedoch eine Menge Fragen offen.

Viele Vorteile von Drupal werden in dieser Architektur nicht verwendet und müssen in der Applikation vollständig neu gebaut werden: Es gibt z.B. keine Form-API, die Benutzereingaben validiert und filtert, um z.B. XSS-Angriffe ins Leere laufen zu lassen.

Die Aufgabe der Validierung von Formular-Eingaben und nutzergenerierten Inhalten lässt sich möglicherweise wieder auf den Drupal Server verlegen, indem die Formulare mit Ajax Forms geladen werden. Hier bin ich jedoch nicht tief genug mit den Konzepten vertraut, um beurteilen zu können, wo die Grenzen der Machbarkeit liegen.

Sobald für einen einzigen Seitenaufruf sehr viele unterschiedliche REST-Requests gegen den Server erforderlich sind, wird der Server recht schnell langsam werden.

Einen sehr guten Artikel "Headless Drupal" - The Cake is a Lie gibt es von Sebastian Siemssen aka fubhy.

Alternative Konzepte mit Facebook BigPipe und GraphQL

Andere moderne Konzepte, Daten abzufragen und auszuliefern, stellen z.B. die von Facebook entwickelten Anwendungen "BigPipe" sowie GraphQL dar.

BigPipe teilt die gesamte Seite in verschiedene Segmente auf, die parallelisiert geladen und gerendert werden. Diese einzelnen Segmente lassen sich serverseitig unterschiedlich cachen und stellen dadurch eine weitere Entlastung für den Server dar.

Mit GraphQL lassen sich Inhalte der Website über eine Abfragesprache selektieren und mit einem einzigen Kontakt zusammenhängend abgefragen. Auf diese Weise lässt sich die Zahl der REST-Anfragen reduzieren.

An einer – derzeit noch im Experimentalstadium befindlichen – Implementierung von BigPipe für Drupal wird bereits gearbeitet.

Ein Aspekt des Internets der Dinge: Auf dem Venice Beach sponsort Toyota ein freies WLAN

Fazit

Technisch eröffnen sich gerade sehr viele neue Möglichkeiten, wie sich individualisierte Seiten performant ausliefern lassen.

Meines Erachtens kommt es nun darauf an, aus den verschiedenen Zutaten Best Practices für die Erstellung moderner Websites und Services für das Web 3.0 zu entwickeln.