Kopfloser Körper mit Druplicon in der Hand in einer schaurigen Friedhofskulisse bei Nacht

Headless CMS - State of the Art oder teures Risiko?

Wir schauen uns an, wann der Headless-Ansatz bei der Entwicklung von Web-Applikationen und Websites Sinn macht - und wann man besser die Finger davon lassen sollte

Stellen wir uns folgendes Szenario vor: ein großer Kunde plant, seine komplette PrĂ€senz im World Wide Web auf ein neues Content-Management-System umzustellen. Die Wahl fĂ€llt dabei auf Drupal. Das Projekt ist sehr umfangreich und auf mehrere Jahre ausgelegt:

  • erst soll die Hauptseite auf Drupal umgestellt werden
  • und dann sollen nach und nach sowohl die Internet-Auftritte von untergeordneten Abteilungen, die Websites von Projekten sowie die Systeme von ĂŒber das Internet zugĂ€nglichen Online-Diensten, die angeboten werden, ebenfalls auf Drupal migriert werden
  • alles soll dabei in einem einheitlichen Corporate-Design gehalten werden
  • der Großteil der Projekte ist dafĂŒr ausgelegt, ĂŒber viele Jahre hinweg betrieben, gewartet und teils kontinuierlich weiterentwickelt zu werden. Dies ist mit ein Grund, warum die Wahl auf Drupal gefallen ist, das seit der Version 8 die Anforderungen aus Enterprise-Projekten zu langen Betriebszeiten ĂŒber mehrere Haupt-Releases hinweg bedienen kann


Die ausgewĂ€hlte Agentur ĂŒberzeugt den Kunden nun davon, dass es fĂŒr das gegebene Anwendungsszenario eine gute Idee sei, einen Headless-Ansatz zu fahren.

Warum diese Empfehlung gegeben wird, bleibt unklar. Sei es, weil "headless" oder "decoupled" gerade in aller Munde und als Ausdruck von State-of-the-Art-Entwicklung verkauft wird - sei es, weil die Agentur sich davon einen Geschwindkeits- oder Effizienzvorteil entspricht - oder sei es, weil die Agentur-Strategie jetzt ist, den Headless-Ansatz zu fahren, unabhĂ€ngig von den konkreten Anforderungen, die Kundenprojekte stellen.  Wie auch immer die GrĂŒnde sein mögen, jedenfalls gelingt es der Agentur, den Kunden zu ĂŒberzeugen und im ersten Projektschritt die Umsetzung der neuen Hauptseite mit dem Headless-Ansatz zu starten.

Um zu bewerten, ob die Entscheidung der Agentur fĂŒr das Anforderungsprofil des Kunden eine gute Wahl war, gehen wir jetzt einen Schritt zurĂŒck und schauen uns an, fĂŒr welche technischen Konzepte die gerne auch mal als "Buzzwords" genutzten Begriffe "Headless CMS" bzw. "Decoupled CMS" eigentlich stehen.

Was hat es mit dem Begriff "Headless-CMS" eigentlich auf sich?

Klassische „gekoppelte“ Content-Management-Systeme wie Drupal vereinen sowohl die Administration von Inhalten als auch deren Darstellung in einer gemeinsamen technischen Plattform.

Man kann aber auch die technische Entscheidung treffen, ein CMS nur fĂŒr die Inhalts-Administration zu nutzen und u.a. die Datenausgabe getrennt ĂŒber eine andere Software zu regeln. In diesem Fall spricht man von einem so genannten „Headless CMS“, weil das CMS selbst keine BenutzeroberflĂ€che fĂŒr den Endnutzer im Frontend mehr bereitstellt.

Ein Headless-CMS ist somit ein Content-Management-System (was wiederum auch Drupal sein kann), bei dem die Verwaltung der Inhalte im Backend von der Ausgabe dieser Inhalte im Frontend vollstÀndig getrennt wurde.

Die Darstellung im Frontend, aber auch die Bereitstellung von Interaktionselementen wie z.B. Formularen ĂŒbernimmt dann die separate Software – ein so genanntes Frontend Framework. Dieses kommuniziert dann ĂŒber Schnittstellen – auch APIs genannt – mit dem (Drupal-)Backend. Es fragt also von dort ĂŒber besagte Schnittstellen Inhalte an oder liefert darĂŒber Nutzer-Eingaben an das Backend zurĂŒck.

Begriffliche Differenzierung: Headless vs. Decoupled

Im Kontext der Entwicklung von Web-Applikationen beziehen sich die Begriffe "headless" und "decoupled" auf zwar verwandte, aber trotzdem unterschiedliche ArchitekturansÀtze:

Headless:

  • bei einer headless Architektur wird die Frontend-OberflĂ€che (der "Kopf") von der Backend-Logik (dem "Körper") getrennt
  • das bedeutet, dass das Backend, das fĂŒr die Datenverarbeitung, GeschĂ€ftslogik und Datenbankinteraktion verantwortlich ist, unabhĂ€ngig vom Frontend existiert
  • im Fall von Webanwendungen kann das Frontend eine separate Anwendung sein, die ĂŒber eine API auf das Backend zugreift, um Daten abzurufen und anzuzeigen
  • Headless-AnsĂ€tze bieten FlexibilitĂ€t und ermöglichen es Entwicklern, verschiedene Frontend-Technologien zu verwenden, ohne das Backend Ă€ndern zu mĂŒssen.

Decoupled:

  • eine entkoppelte Architektur Ă€hnelt der headless Architektur, aber sie kann auch bedeuten, dass Backend und Frontend lose gekoppelt sind, anstatt vollstĂ€ndig getrennt zu sein
  • in einer entkoppelten Architektur gibt es möglicherweise eine gewisse AbhĂ€ngigkeit zwischen Frontend und Backend, aber sie sind nicht stark miteinander verflochten.
  • das Frontend kann bestimmte Teile des Backends wiederverwenden oder direkt darauf zugreifen, wĂ€hrend es dennoch seine eigene Logik und PrĂ€sentation besitzt.
  • im Gegensatz zur headless Architektur könnte bei einer entkoppelten Architektur das Frontend immer noch einige serverseitige Vorlagen oder PrĂ€sentationslogik verwenden, die direkt aus dem Backend bereitgestellt werden.


Somit kann man sagen, dass "headless" eine strengere Trennung von Frontend und Backend bedeutet, wÀhrend "decoupled" auf eine weniger strenge, aber immer noch bedeutende Trennung hindeutet, wobei Frontend und Backend weniger stark miteinander verbunden sind.

Mögliche Vorteile eines Headless-CMS

Die Entscheidung, das Frontend vom Backend entweder zu entkoppeln oder gĂ€nzlich "headless" zu gestalten, kann in bestimmten Einsatzszenarien richtig und sinnvoll sein. Einige Beispiele dafĂŒr sind:

  • Multikanal-Veröffentlichung: Wenn Inhalte auf verschiedenen Plattformen (Web, mobile Apps, IoT-GerĂ€te) veröffentlicht werden mĂŒssen, ermöglicht ein Headless CMS die flexible Bereitstellung von Inhalten auf unterschiedlichen EndgerĂ€ten.
  • individualisierte Benutzererlebnisse: Wenn maßgeschneiderte Benutzererlebnisse („user experiences, auch bekannt als „UX“) fĂŒr verschiedene Zielgruppen oder Benutzersegmente benötigt werden, erlaubt die Trennung von Content und PrĂ€sentation die Entwicklung unterschiedlicher Frontends fĂŒr jede Gruppe.
  • bessere Leistung und Skalierbarkeit: Projekte mit hohen Anforderungen an Leistung und Skalierbarkeit, insbesondere wenn Inhalte auf globaler Ebene verteilt sind, können von der Entkopplung von Frontend und Backend profitieren.
  • Integration mit Drittanbieterdiensten: Wenn eine Vielzahl von Drittanbieterdiensten integriert werden mĂŒssen, kann ein Headless CMS die nahtlose Integration durch APIs erleichtern.
  • insbesondere im Kontext Headless-Drupal: Reduktion des Bedarfs an Drupal-Spezialisten. Drupal ist ein funktionsmĂ€chtiges Framework, dessen Potential am besten genutzt werden kann, wenn man Erfahrung in der Entwicklung damit mitbringt. Erfahrene Drupal-Entwickler:innen sind jedoch ein "knappes Gut". Somit kann es z.B. ein Geschwindigkeitsvorteil sein, wenn das Frontend von Drupal entkoppelt ist, da die fĂŒr das Frontend zustĂ€ndigen entwickelnden Personen dann nicht notwendigerweise ĂŒber Drupal-Kenntnisse verfĂŒgen mĂŒssen. 

Mögliche Nachteile eines Headless-CMS    

Dem gegenĂŒber stehen folgende Nachteile und Risiken, die bei einer anteiligen oder vollstĂ€ndigen Entkopplung des Frontends vom Backend eintreten können:

  • KomplexitĂ€t: Die Trennung von Frontend und Backend fĂŒhrt zu einer erhöhten KomplexitĂ€t im Vergleich zu traditionellen CMS. Die entwickelnden Personen mĂŒssen sich mit verschiedenen APIs und Technologien auseinandersetzen.
  • Kosten: Die Implementierung eines Headless CMS ist somit in der Regel kostenintensiver als der „traditionelle“ Ansatz. Wenn das umzusetzende System dann aber die Vorteile eines Headless-Design-Ansatzes kaum oder gar nicht nutzen kann, wird es schnell unwirtschaftlich, trotzdem einen Headless-Ansatz zu verfolgen.
  • Frontend-Technologien: Da beim Headless CMS die Trennung von Backend und Frontend vorliegt, ist das Frontend in der Regel von der Wahl der Technologie und Frameworks abhĂ€ngig. Frontend-Technologien können sich schnell weiterentwickeln, und es kann erforderlich sein, das Frontend regelmĂ€ĂŸig zu aktualisieren, um von neuen Funktionen, Sicherheitsupdates und Leistungsverbesserungen zu profitieren. Dies bedeutet also einen zusĂ€tzlichen Wartungsaufwand neben der ebenfalls notwendigen Wartung fĂŒr das eigentliche CMS.
  • End-of-Life von Frontend-Frameworks: Es besteht die Möglichkeit, dass das Frontend-Framework, das fĂŒr die Darstellung verwendet wird, schneller sein "end of life" erreicht als das CMS selbst. Dies kann dazu fĂŒhren, dass das Frontend aktualisiert oder sogar auf ein komplett neues Framework migriert werden muss, um weiterhin UnterstĂŒtzung und Sicherheitsupdates zu erhalten.
  • Entwickler-Expertise: Die VerfĂŒgbarkeit von EntwicklerInnen mit Fachkenntnissen in den eingesetzten Frontend-Technologien ist wichtig. Wenn ein Framework an PopularitĂ€t verliert oder nicht mehr aktiv unterstĂŒtzt wird, kann es schwieriger sein, qualifizierte EntwicklerInnen zu finden. Zudem besteht dann auch das Risiko, "aufs falsche Pferd gesetzt" zu haben, wenn das gewĂ€hlte Frontend-Framework in der "Gunst" der Entwickelnden sinkt und in der Folge nicht mehr weiterentwickelt wird. Dies ist weniger problematisch bei Projekten, die ohnehin alle paar Jahre neu aufgesetzt werden oder nur eine begrenzte Lebensdauer haben. Ist das Zielprojekt jedoch auf einen Betrieb von vielen Jahren ausgelegt, bietet der nicht-entkoppelte Ansatz viel mehr Betriebssicherheit ĂŒber einen langen Software-Zyklus hinweg.
  • insbesondere im Kontext Headless-Drupal: viele Contrib-Module, die als Erweiterungen fĂŒr den Drupal-Kern verfĂŒgbar sind, sind darauf angewiesen, die Ausgabe im Frontend modifizieren zu können. Dies können sie aber nur dann ohne weiteres, wenn Drupal selbst fĂŒr das Rendering des Frontends zustĂ€ndig ist. Beim Headless-Ansatz muss hier also ggf. erheblicher zusĂ€tzlicher Implementierungsaufwand betrieben werden, damit die eingesetzten Module so wie gewĂŒnscht funktionieren und die Ausgabe im Frontend beeinflussen können.

Auf den Kontext kommt es an

Der Vergleich zeigt: es kommt immer auf den Kontext an, in welchem ein Online-Projekt geplant, entwickelt und betrieben werden soll. Dieser Kontext definiert, ob das Projekt eher einen Nutzen aus dem Headless-Ansatz zieht - oder ob die Nachteile ĂŒberwiegen wĂŒrden.

ZurĂŒck zu unserem Szenario: war "Headless Drupal" hier eine gute Idee?

Man ahnt es schon: nein, war es nicht. Das Anwendungsszenario des Kunden kann von den Vorteilen, die Headless bietet, nicht profitieren:

  • er betreibt keine Multikanal-Veröffentlichung, der primĂ€re Weg des Informations-Transfers ist der Web-Browser auf Desktop- und MobilgerĂ€ten
  • automatische Zielgruppen-Segementierung ist irrelevant
  • die Websites unterliegen kontinuierlichem, mĂ€ĂŸigem Traffic und weisen keine Lastspitzen auf
  • die Anforderungen an das Frontend Ă€ndern sich ĂŒber die Jahre praktisch nicht


Statt dessen schlagen die genannten Nachteile deutlich zu Buche:

  • höhere Betriebs- und Entwicklungskosten
  • höhere Wartungskosten
  • teilweise Parallelbetrieb von Technologien erforderlich, wenn der Headless-Ansatz etwa fĂŒr kleinere Projektseiten unwirtschaftlich ist und somit fĂŒr diese ein klassisches Twig-Template fĂŒr das Frontend maintained werden muss

Wie stehen wir bei erdfisch zu Headless?

Im Regelfalle setzen wir unsere Web-Projekte nicht komplett "headless" um. Das liegt aber nicht daran, dass wir diesen technologischen Ansatz im Grundsatz ablehnen oder uns dafĂŒr die Kompetenz fehlt. Vielmehr ist der Grund, dass sich aus dem Projekt-Kontext derjenigen Projekte, die wir umsetzen und betreuen, in der ĂŒberwiegenden Mehrzahl der FĂ€lle ergibt, dass Headless dem Kunden nicht ausreichend Vorteile bieten wĂŒrde, um die Nachteile zu ĂŒberwiegen. Konkret sind das Projekte, die

  • einen relativ großen Funktionsumfang aufweisen
  • unterschiedliche Formen von konstanter Nutzer-Interaktion aufweisen
  • einer stetigen Weiterentwicklung unterliegen
  • fĂŒr den Kunden ein erhebliches einmaliges wie auch kontinuierliches Investment bedeuten
  • und somit auf eine Laufzeit von mindestens 5 oder gar bis zu 10 Jahren ausgelegt sind.


FĂŒr diese Projekte ist langfristige Technologiesicherheit besonders wichtig. Diese bietet das fĂŒr den Enterprise-Einsatz besonders geeignete Web-Content-Management-Framework Drupal - sowohl fĂŒr das Backend als auch fĂŒr das Frontend. Setzt man Headless ein, macht man sich jedoch von einem zweiten Technologie-Stack abhĂ€ngig und muss darauf bauen, dass dieser ebenso langfristig unterstĂŒtzt und weiterentwickelt wird, wie das bei Drupal der Fall ist. 

Unsere Erfahrungen aus der Vergangenheit haben gezeigt, dass das bei weitem nicht immer der Fall ist. Entsprechend vorsichtig sind wir daher damit, den Weg einzuschlagen, den die (nicht so ganz) fiktive Agentur in unserem Eingangs-Szenario gegangen ist. Denn letztlich ist immer entscheidend, das fĂŒr das konkrete Anforderungsprofil des Kunden am besten passende technologische Konzept anzuwenden.

BewÀhrtes kann zwar mitunter "langweilig" sein - aber man kann sich eben im Ernstfall auch darauf verlassen. Und darauf kommt es im Enterprise-Kontext an.

Gibt es Ausnahmen?

Aber sicher: keine Regel ohne Ausnahme. Auch bei unseren umfangreichen und auf langfristigen Betrieb angelegten Drupal-Kundenprojekten gibt es immer wieder Szenarien, wo sich ein Decoupled-Ansatz lohnen kann. FĂŒr diese FĂ€lle fahren wir dann einen Mittelweg statt "ganz oder garnicht", den wir jetzt zum Abschluss noch kurz vorstellen möchten. Hierbei handelt es sich um den so genannten "Progressive Decoupled"-Ansatz.

WofĂŒr steht Progressive Decoupling?

Progressive Decoupling ist wie schon kurz beschrieben ein Mittelweg. Nicht das komplette System ist dann entweder monolithisch oder headless aufgebaut, sondern es werden nur diejenigen Bestandteile entkoppelt, die von den benannten Vorteilen von Headless besonders profitieren. So lassen sich beispielsweise "Widgets" mit einem klar definierten Funktionsumfang entwickeln, die dann ein Decoupled Frontend haben und javascriptbasiert clientseitige Nutzerinteraktion erlauben, ohne stĂ€ndig mit der Drupal-Datenbank interagieren zu mĂŒssen und ohne die komplette Seite nach Nutzereingaben neu laden zu mĂŒssen. Erst bei Bedarf erfolgt dann der Datenaustausch mit dem via API angebundenen Drupal-Backend.

Diese Widgets werden dann in die ansonsten "klassisch" gerenderte Drupal-Website eingebettet oder können auch separat oder im Kontext einer App betrieben werden. 

Bei klugem Einsatz erhÀlt man auf diesem Weg das beste aus beiden Welten:

  • Bestandteile der Business-Logik, die vom UX-Potential von Frontend-Frameworks besonders profitieren, etwa im Hinblick auf Darstellungsmöglichkeiten oder clientseitiger AusfĂŒhrung, werden decoupled gestaltet
  • wĂ€hrend andere Teile des Projekts, die aus Decoupled oder Headless keinen hinreichenden Nutzen ziehen können, weiter klassisch serverseitig ĂŒber Drupal selbst gerendert werden.

Fazit

Der Ansatz, Web-Projekte vollstĂ€ndig Headless oder Decoupled zu gestalten, sollte wohlĂŒberlegt sein, da man sich mit den Vorteilen auch einige gewichtige Nachteile oder Risiken ins Haus holt. Insbesondere bei auf lange Laufzeiten angelegten Enterprise-Projekten, die von den Vorteilen von Headless oder Decoupled tendenziell weniger profitieren, ist von einer Entkoppelung des Frontends vom Backend eher abzuraten. Ein praktikabler Mittelweg kann dann jedoch der Progressive Decoupling Ansatz sein, bei welchem nur diejenigen Teile der Business-Logik entkoppelt werden, die das Potential dieses Ansatzes auch ausnutzen können.

 

Bildnachweis:

Titelbild basierend auf der Arbeit von chanwity435363/Vecteezy