Headless CMS – State of the Art oder teures Risiko?

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.

Bildnachweis:

Titelbild basierend auf der Arbeit von chanwity435363/Vecteezy