"Kopflose" Content Management Systeme: enge Verzahnung oder vollständige Aufteilung?

Headless CMS – Backend und Frontend flexibel entkoppeln
Kommentare

Das Thema „Headless“ Content-Management-Systeme, also die Trennung von Backend und Frontend, wird unter Entwicklern kontrovers diskutiert. Wichtig ist, im Einzelfall den richtigen Weg zwischen enger Verzahnung oder vollständiger Aufteilung zu finden.

Die Weiterentwicklung von Websites in Richtung interaktiver Web-Applikationen und der Bedarf an Multi-Channel-Publishing haben einen bedeutsamen Trend verursacht. Durch die Entkopplung von Backend und Frontend eines Content-Management-Systems (Headless CMS) erhalten Frontend-Entwickler die volle Kontrolle über die Abläufe und Gestaltung im Frontend. Mit Client-seitigen Frameworks können Entwickler interaktive Websites produzieren, die sich wie Applikationen verhalten. Neue Daten erscheinen automatisch, es ist kein Refresh der Seite mehr notwendig. Anwender können mit der Applikation arbeiten, während Teile davon dynamisch nachgeladen werden.

Eine weitere Stärke entkoppelter Architekturen sind getrennte Teams: Da Frontend- und Backend-Entwickler nicht mehr den vollständigen Umfang einer monolithischen Architektur verstehen müssen, können sie unabhängig voneinander arbeiten. Gut organisiert lassen sich Projekte damit deutlich beschleunigen.

Entkoppelte CMS

Das traditionelle monolithische (links) und das vollständig entkoppelte „headless“ Architekturparadigma (rechts). (Quelle: Acquia)

Bevor die Entkopplung umgesetzt wird, sollte zunächst überprüft werden, ob tatsächlich auf all die Frontend-Funktionalitäten, die ein CMS kostenlos bereitstellt, verzichtet werden kann: Layout- und Display-Management, Content Previews, Authentifizierung sowie XSS (Cross-Site-Scripting) und CSRF (Cross-Site-Request-Forgery) Protection. Wer entkoppelt, muss derartige Funktionalitäten nachbauen. In einigen Fällen ist das hilfreich, in anderen nicht. Anders ausgedrückt: Ob Backend und Frontend entkoppelt werden oder nicht bedarf einer Einzelfallentscheidung.

Vollständige Entkopplung ist nicht immer die beste Lösung

Ein CMS ist traditionell dafür gedacht, Websites zu erstellen – und keine Web-Applikationen. Die Grenzen zwischen beiden verschwimmen aber zunehmend. Dass lässt sich am Beispiel einer Musik-Website verdeutlichen, die inhaltsreiche und redaktionell gepflegte Kritiken veröffentlicht  und gleichzeitig den Ticketverkauf für Konzerte anbietet. Für die Artikel werden Tools benötigt, um den Inhalt auf der Seite ansprechend zu strukturieren. Der Ticketverkauf ist jedoch auf Interaktivität angewiesen und man möchte diesen dynamischen Vorgang am liebsten direkt auf der Seite abbilden. Mit Drupal 8 beispielsweise lassen sich solche Layouts komfortabel umsetzen. Bei diesem Anwendungsszenario wiegt jedoch in einer vollständig entkoppelten Architektur der Nachteil, die in Drupal standardmäßig vorhandenen Funktionalitäten mit einem Client-seitigen Framework nachbauen zu müssen, weit schwerer als die Vorteile, die ein solches Framework für die Frontend-Entwicklung bieten würde.

Vollständig entkoppeltes CMS

Die Architektur eines vollständig entkoppelten Content-Management-Systems. (Quelle: Acquia)

Ferner kann eine vollständig entkoppelte Architektur im Einzelfall auch zu Performanceproblemen führen. Wichtig ist, dass Anwender die gesuchten Informationen so schnell wie möglich auf der Website sehen und darauf sofort reagieren können. Ein optimal ausgelegtes CMS ist in diesem Fall einem Client-seitigen Framework überlegen.

Viele Inhalte dieser fiktiven Musik-Website lassen sich zwischenspeichern, etwa die Navigationsleiste und andere statische Seitenelemente. In einem herkömmlichen Modell der Bereitstellung von Inhalten können jedoch einige Vorgänge, die längere Zeit zur Ausführung benötigen, die Ausführung anderer, einfacherer Seiteninhalte behindern. In unserem Beispiel könnten dies etwa benutzerspezifische Datenblöcke sein, die seine Lieblingslieder oder Konzerte enthalten.

Client-seitige, dynamische Auslieferung von Inhalten

An dieser Stelle wäre eine selektive Verarbeitung wünschenswert, bei der die allgemeingültigen Datenblöcke als erstes und die umfangreichen Datenblöcke später geladen werden. Mit BigPipe, einem Ansatz zur Client-seitigen, dynamischen Auslieferung von Inhalten und jetzt Bestandteil von Drupal 8, lassen sich die Seiten schrittweise ausliefern. Es wird zunächst das Webseitengerüst mit allen allgemeingültigen Inhalten an den Browser übermittelt und erst im zweiten Schritt folgen die personalisierten Inhalte.

Damit eine vollständig entkoppelte Website schnellere Ladezeiten als eine individuell mit BigPipe angepasste Drupal-8-Website erzielt, müssten große Teile der Smart Caching Logic, des Client Caches und der kontinuierlichen Synchronisation des Client Caches mit Serverdaten nachgebaut werden. Darüber hinaus dauert – gerade auf mobilen Endgeräten – das Parsen und die Ausführung von JavaScipt zur Generierung von HTML länger als der einfache Download von vorgefertigten HTML-Elementen. Um diesen Nachteil auszugleichen, müsste man den verwendeten JavaScript-Code aufwendig optimieren.

Client-seitige Frameworks müssen mit einigen unvermeidlichen Nachteilen umgehen, wenn sie das gesamte Rendering auf der Client-Seite vornehmen. Bei vergleichsweise langsamen Verbindungen, wie sie für mobile Endgeräte typisch sind, bremst Client-seitiges Rendering die Geschwindigkeit, verbraucht mehr Akkuleistung und verursacht gegebenenfalls unerwartete Wartezeiten. Da die meisten Softwareentwicklungen lokal und nicht unter realen Bedingungen auf mobilen Endgeräten getestet werden, bringen die Trägheit und Unzuverlässigkeit von mobilen Datenverbindungen in der Praxis jede entkoppelte Website – egal, ob sie mit Drupal oder einem anderen CMS erstellt wurde – schnell in Schwierigkeiten.

Die Zukunft gehört der schrittweisen Entkopplung

Bei einer vollständigen Entkopplung von Backend und Frontend stehen zentrale CMS-Funktionalitäten und BigPipe-Rendering nicht zur Verfügung. Was aber wäre, wenn sich die Entkopplung mit beiden Optionen verbinden ließe? Eine Lösung dafür bieten entkoppelte Komponenten. Anstatt eine gesamte Website zu entkoppeln werden nur einzelne Teile oder Bausteine entkoppelt.

Schrittweise entkoppeltes CMS

Bei einer progressiven Entkopplung gibt der CMS Renderer immer noch das Skelett einer Seite aus. (Quelle: Acquia)

Eine solche Komponenten-gesteuerte entkoppelte Architektur bietet deutliche Vorteile gegenüber einer vollständig entkoppelten Architektur. Insbesondere das bewährte Content-Management und die Workflows, sowie das Display- und Layout-Management stehen weiterhin zur Verfügung. Bei der Musik-Website lässt sich beispielsweise der Block mit den Musikstücken, die ein Anwender in der letzten Woche am häufigsten hörte, an eine beliebige Stelle auf der Website verschieben. Ein Frontend-Entwickler könnte dann für Interaktivität sorgen, indem ein Benutzer ein Stück aus dieser Liste anhört oder den Titel ad hoc zur Favoritenliste hinzufügt. Ein Content-Editor könnte mit wenigen Mausklicks zum Beispiel auch die Liste der am häufigsten gehörten Titel von der rechten zur linken Seitenleiste verschieben, ohne dass dazu die Unterstützung eines Frontend-Entwicklers benötigt wird.

Schrittweise Entkoppeln: Progressive Decoupling

Dieser Ansatz wird als schrittweises Entkoppeln (Progressive Decoupling) bezeichnet. Die Entwickler legen fest, welche Teile einer Webseite und welche Komponenten vom Drupal-Frontend oder dem dedizierten Drupal-Rendering losgelöst werden. Ein Progressively Decoupled Drupal ist damit ein Schritt in Richtung „assemblierter Websites“. Entwickler und Editoren können damit ohne großen Programmieraufwand attraktive Websites erstellen.

Damit eröffnet sich ein breites Spektrum von Optionen zwischen den beiden Polen einer vollständigen Entkopplung und einer traditionellen CMS-Lösung. Die vollständige Entkopplung stellt die Inhalte einer einzelnen Zielgruppe oder mehreren Gruppen von Anwendern (Many-Headed Drupal) bereit, beispielsweise als mobile Applikation, interaktiver Kiosk oder auf dem TV. Progressive Decoupling geht noch einen Schritt weiter, da Teile einer Website vollständig und andere schrittweise entkoppelt werden können. Es gelten die Prinzipien der friedlichen Koexistenz. Aber auch dann bleibt immer noch Einiges zu tun.

Koexistenz von entkoppelten CMS

Bei einem sogenannten many-headed Drupal existieren vollständig entkoppelte Applikationen Seite an Seite mit schrittweise entkoppelten Pages, deren Skelett vom CMS angeordnet werden. (Quelle: Acquia)

Netzwerk-Performance in einer REST-Architektur

Eine der größten Herausforderungen für Frontend-Entwickler ist die Netzwerk-Performance mit REST (Representational State Transfer). Eine REST-Query, die Inhalte aus verschiedenen Quellen zusammenträgt, erfordert für jeden individuellen Vorgang eine Kommunikation mit dem Server, die in hoher Anzahl beidseitig viele Ressourcen verbrauchen kann.

Lösen lässt sich dieses Problem mit der Erstellung individueller API-Endpunkte, zum Beispiel in Views. Die Verwaltung dieser Endpunkte kann sich jedoch sehr schnell als Mammutaufgabe erweisen. Wird auf der anderen Seite statt vieler Endpunkte nur ein Endpunkt verwendet, muss bei einem Update der gesamte JavaScript-Code, der auf diesen Endpunkt angewiesen ist und die Daten aufnimmt, angepasst werden. Diese Art des Endpunkt-Managements bedeutet aber, dass die Frontend-Entwickler auf abgeschlossenen Vorarbeiten von Backend-Entwicklern angewiesen sind, was zu neuen Bottlenecks führen kann.

Trotz Entkopplung besteht weiterhin die Notwendigkeit, bessere Möglichkeiten zu finden, um Daten zur richtigen Zeit auf der Client-Seite bereitzustellen. Da Webseiten und Applikationen immer stärker über Komponenten gesteuert sind, steigt die Komplexität der auszuführenden Abfragen, deren Ergebnisse am besten sofort zur Verfügung stehen sollten. Wünschenswert wären Lösungen, um nur genau die benötigten Daten abzufragen. Eine interessante Möglichkeit bietet die von Facebook entwickelte Datenabfragesprache GraphQL. Damit lassen sich bestimmte Inhalte auswählen und mit einer einzigen Query zusammenhängend abfragen. So entfallen die bei komplexen Abfragen ansonsten üblichen vielen Roundtrips zu Servern, es müssen keine unterschiedlichen Endpunkte verwaltet werden und es ist keine Versionierung erforderlich. GraphQL ist nicht nur auf Facebook beschränkt. Es gibt auch bereits ein Projekt, bei dem es um den Einsatz von GraphQL zusammen mit Drupal geht.

Aufmacherbild: boy with TV instead of head via Shutterstock / Urheberrecht: Who is Danny

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -