In der Welt der Content-Management-Systeme hat der Begriff \"Headless CMS\" in den letzten Jahren viel Aufmerksamkeit erregt. Thomas Schedler (Co-Founder & CEO von Sulu GmbH) hat sich die Vor- und Nachteile einmal genauer angeschaut.

Zu den propagierten Vorteilen der Headless-Architektur gehören, dass Inhalte nur einmal erstellt werden müssen und anschließend in jedem beliebigen Format ausgegeben werden können. Inhalte sind zukunftssicher abgelegt und in Bezug auf die eingesetzten Frontend-Technologien hat man die freie Wahl. Gleichwohl sollte man die Vor- und Nachteile einer Headless-Architektur und ihrer Relevanz für bestimmte Anwendungsfälle gut abwägen und nicht blind dem Hype folgen.

Eine bestimmte Art von CMS und ein Modus

Was bedeutet „headless“? Ich betrachte den Begriff „headless“ aus zwei verschiedenen Blickwinkeln. Er beschreibt eine bestimmte Art von CMS und ein Modus, in dem ein CMS eingesetzt wird. Im engeren Sinne besteht ein Headless-CMS nur aus einer Administrationsoberfläche für die Pflege, einer Datenbank für die Speicherung und einer API für das Konsumieren von Inhalten. Es gibt keine Ausgabeschicht. Um die im CMS abgelegten Inhalte auszugeben, muss also eine Entwicklerin oder ein Entwickler ein Frontend bereitstellen, das über API-Abfragen auf die Inhalte zugreift, z. B. über eine REST oder GraphQL API. Diese Architektur hat im Speziellen Vorteile, wenn eine Website nur ein Ausgabekanal von vielen ist. Ein Headless-CMS kann Inhalte für Sprachassistenten, Chatbots, Smartwatches, mobile Anwendungen, Websites und jedes neue Ausgabegerät, das in Zukunft hinzukommen kann, bereitstellen.

Paradigmenwechsel bei den Content-Management-Systemen

Headless ist ein Paradigmenwechsel – weg vom traditionellen CMS mit enger Kopplung von Inhalten und Ausgabeschicht hin zu einer Architektur, die flexibel genug ist, um Inhalte sowohl in einem Browser auszugeben als auch in einem offenen und flexiblen Content Repository für die unterschiedlichsten Anwendungen bereitzustellen.

Einige Content Management Systeme, wie z. B. Sulu CMS (zu dessen Core-Team ich gehöre), verwenden einen “decoupled” oder “entkoppelten” Aufbau. Sie bringen somit Funktionen eines herkömmlichen CMS mit – also auch eine Ausgabeschicht für die Aufbereitung der Inhalte als Website – sind aber auch in der Lage, im Headless-Modus Inhalte über eine standardisierte API auszuspielen. So kann man die Rendering-Engine vollständig umgehen und die Daten direkt an ein beliebiges Frontend ausliefern. Der Vorteil hierbei ist, dass wenn einer der benötigten Ausgabekanäle eine Website ist, man auf bewährte Technologien für das Website-Rendering zurückgreifen kann. Somit erspart man sich einiges an zusätzlichem Aufwand, der nötig wäre, um ein eigenes Frontend aufzubauen. Trotzdem kann man die Stärken eines Headless-CMS auskosten.

In einigen Fällen kann auch ein Hybrid-Modus Sinn machen. So haben wir z. B. schon Webseiten umgesetzt, bei denen die Rendering-Engine des CMSs die initialen Inhalte zusammen mit einer JavaScript-Applikation ausliefert. Sobald diese geladen sind, werden dem Besucher weitere hoch personalisierte Inhalte über eine API zur Verfügung gestellt. Dieser Ansatz kann effizienter sein, als ein völlig neues Frontend aufzubauen und nutzt die Vorteile einer Headless-Architektur – dort, wo sie sinnvoll sind.

Die Vorteile von Headless-Architektur für Entwickler

In den letzten fünf Jahren ist das Interesse an der Headless-CMS-Architektur enorm gewachsen. Dies spiegelt die Frustration mit der traditionellen CMS-Architektur wieder, die die Ausgabeschicht eng mit den Inhalten verwoben hat. Viele CMSs bieten noch immer lediglich WYSIWYG-Editoren an, und während viele Content-Manager die damit verbundene Benutzerfreundlichkeit schätzen, verbindet diese Arbeitsweise die Inhalte mit einer bestimmten Darstellungsform.

Das Problem wurde erstmals deutlich, als mobile Websites und Apps beliebter wurden. Früher waren Entwickler und Content-Manager eher in der Lage, die genaue Umgebung vorherzusagen, in der die Benutzer ihre Inhalte konsumieren. Mit kleineren Bildschirmgrößen und der Beliebtheit von Smartphone- und Tablet-Anwendungen mussten Menschen, die es gewohnt waren, ihre Arbeit in Word-Dateien und auf Papier zu teilen, damit beginnen, ihre Daten in einer strukturierten Form zu speichern. Jetzt haben wir Smartwatches, Sprachassistenten, Chatbots, In-Car Entertainment, Digital Signage und auch das Internet der Dinge wird schneller Realität, als uns bewusst ist. Inhalte müssen agnostisch gespeichert werden, damit sie für jedes Gerät geeignet sind. Viele Menschen sehen die Headless-Architektur als Lösung für dieses Problem.

Die Vorteile der Headless-CMS-Architektur

Headless-Ansätze versprechen auch weitere Vorteile:

• Frontend-Entwickler können bereits bekannte Technologien wie Angular, ReactJS oder Vue.js verwenden, ohne die Lernkurve für das jeweilige CMS zu durchlaufen. Vielleicht kann dies auch die Rekrutierung von Entwicklern erleichtern
• Inhalte werden auf einer Vielzahl von Geräten wiederverwendbar
• Zugang zu dynamischen, personalisierten und interaktiven Inhalten auf Abruf wird ermöglicht
• Static Site Generators können sich Inhalte holen und HTML-Seiten direkt an ein CDN weiterleiten
• Ein CMS kann nur eine von vielen Datenquellen sein, auf die jeweils über die entsprechenden APIs in einer Frontend-Anwendung zugegriffen wird

Die Nachteile der reinen Headless-CMS-Architektur

Headless ist jedoch kein Allheilmittel. Der größte Nachteil: Wenn man eine Website benötigt, muss man einen neuen „Kopf“ anbauen, der sich um die Präsentation der Inhalte in einem Browser kümmert. CMS erledigen viele dieser Aufgaben out-of-the-box. Es kann daher sein, dass man fehlende Funktionen selbst entwickeln, oder Komponenten von Drittanbietern hinzufügen, muss – auch wenn viele der Headless-CMSs am Markt nach und nach aufholen. Das erhöht die Komplexität des Projekts und den späteren Wartungsaufwand. Wenn man sich für ein reines Headless-CMS entscheidet, muss man sich möglicherweise um folgendes selbst kümmern:

• Umwandlung der Inhalte in HTML (da die Rendering-Engine fehlt)
•  Caching, einschließlich Details wie Cache-Expiring und -Invalidation, damit die Seite performant bleibt
• Bearbeitung und Optimierung von Bildern für verschiedene Kanäle und Geräte
• Zentrales Asset-Management, das Redakteuren eine benutzerfreundliche Mediathek bietet
• Vorschau für Redakteure (in Headless-Setups schwierig zu implementieren)
• Front- und Backend-Usability, die den Bedürfnissen des Kunden entsprechen

Aus meiner Sicht bietet ein decoupled (also „entkoppeltes“) CMS das Beste aus beiden Welten. Die eingebaute Rendering-Engine wird beibehalten, während die Inhalte im Headless- oder Hybrid-Modus für andere Geräte verfügbar sind.

Headless-Architektur kann nicht alle Versprechen einlösen

Die Headless-Architektur hat einige objektive Nachteile – und Bereiche, in denen sie noch Nachholbedarf aufweist. Aber auch einige der angeblichen Vorteile finde ich entweder unrealistisch oder zumindest nicht durch einen bloßen Einsatz eines Headless-CMS einlösbar.

Manche hoffen, ihre Redakteure müssen Inhalte nur einmal eingeben, damit sie anschließend überall ausgegeben werden können. Wer sich für Headless entscheidet, weil man glaubt, Zeit zu ersparen, könnte enttäuscht werden. Nur weil auf die Inhalte über eine API zugegriffen wird, bedeutet dies nicht, dass sie automatisch für die Ausgabe auf einem beliebigen Gerät optimiert sind. Wenn eine Smartwatch beispielsweise viel kürzere Artikel-Überschriften und Teaser benötigt, muss man seinen Redakteuren dafür ein zusätzliches Feld anbieten. Und denen kostet es Zeit, dieses Feld auszufüllen. Alternativ kann man es dem Zufall überlassen oder ein Zeichenlimit festlegen.

Die Lösung dieses Problems ist nicht neu: moderne CMS bieten seit langem keinen großen WYSIWYG-Editor mehr an, sondern stellen stattdessen die notwendig Felder bereit, um strukturierte Inhalte aufzubereiten und die damit auch gewährleisten, unterschiedliche Kanäle optimiert zu bespielen. Es reicht also nicht aus, ohne weitere Überlegungen, einfach auf ein Headless-CMS zu setzten.
Ein weiteres verlockendes Argument für Headless ist seine vermeintliche Zukunftssicherheit. Indem man seine Inhalte über ein API zugänglich macht, können zukünftige Anwendungen darauf zugreifen und Benutzern ermöglichen, mit bestehenden Inhalten auf einer neuen Art und Weise zu interagieren.

Wenn das Content-Repository gut strukturiert ist, wird ein API tatsächlich die Chancen verbessern, z. B. künftige IoT-Geräte zu integrieren. Aber man muss die Vorarbeit dafür leisten und es gibt keine Garantie, dass die Inhalte nicht ohnehin für zukünftige Anwendungen adaptiert werden müssen.
Während also Headless Content-Management-Ansätze Redakteuren helfen können, Inhalte für ein einmaliges Endbenutzer-Erlebnis auf jedem Gerät anzupassen und zukunftssicher zu gestalten, braucht es mehr als nur die bloße Bereitstellung der Inhalte über eine API, um diese Versprechen einzulösen.

Auf Headless umstellen, ohne den Kopf zu verlieren

Auch wenn die Vorteile einer Headless-Architektur oft stark vereinfacht dargestellt werden, erinnern sie uns daran, wie wichtig eine hervorragende UX für Redakteure (Editor Experience), die damit verbundene Produktivität und Wiederverwendbarkeit von Inhalten und Zukunftssicherheit der eingesetzten Lösung sind.

Des Weiteren erleichtert ein Bewusstsein für Kosten, die jeweils mit Headless, Decoupled, Hybrid und traditionellen Ansätzen verbunden sind, die Durchführung einer genauen Kosten-Nutzen-Analyse in der Konzeptphase, welche wiederum einen Einfluss auf die Entscheidungsfindung haben sollte. Hier sind meine Empfehlungen für eine Herangehensweise in die Praxis.

Empfehlung 1: Effektive Content-Architecture

Eine Stärke von CMS wie Sulu ist der semantische, blockbasierte Ansatz. Man kann standardisierte Templates für Redakteure bereitstellen, die dann den Inhalt durch Hinzufügen vordefinierter Blöcke aufbauen. Anstatt eine Bildergalerie inmitten eines WYSIWYG-Texteditor zu platzieren, fügt der Redakteur einen entsprechenden Block hinzu und befüllt ihn aus der Mediathek. Anstatt eine Telefonnummer irgendwo einzusetzen, kann ein semantisches Telefon-Feld einen Anruf auf einem Smartphone oder einigen Smartwatches initiieren, während es auf Desktop-Browsern bloß angezeigt wird. Die Erstellung einer Content-Architektur, die Inhaltsbereiche so markiert, dass sie unabhängig vom Ausgabemedium angezeigt werden können, trägt zur Zukunftssicherheit der Inhalte bei.

Um ehrlich zu sein: die korrekte Eingabe und Kennzeichnung von Inhalten wird für die Redakteure mit mehr Arbeit verbunden sein. Je mehr Optimierungen für bestimmte Ausgabegeräte vorgenommen werden, desto mehr Felder müssen ausgefüllt werden. In dieser Hinsicht sollte man darauf achten, es seinen Redakteuren so leicht wie möglich zu machen, produktiv zu arbeiten. Wiederverwendbare Snippets zum Beispiel und standardisierte Fallback-Felder, die bei Bedarf überschrieben werden können, reduzieren die Arbeitslast. Dasselbe gilt für übersichtliche Admin-Oberflächen mit sorgfältig durchdachten Hilfetexten.

Empfehlung 2: Verstehe deinen Anwendungsfall und entscheide entsprechend

Es gibt ein paar Faustregeln, die bei der Auswahl des richtigen Ansatzes helfen.
Ich rate zur Verwendung eines herkömmlichen CMSs, oder eines decoupled CMSs und die eingebaute Rendering-Engine, wenn man:

• eine Marketing-Website baut
• nur statische Inhalte und einen Blog veröffentlicht
•  viel Traffic erwartet
• Inhalte nur auf Desktop- und mobilen Geräten ausgeben werden

Es sprechen zwar keine Gründe dagegen, in diesem Fall ein traditionelles CMS zu verwenden, aber ich würde trotzdem davon abraten. Ein decoupled CMS wird in Zukunft mehr Flexibilität bieten, falls weitere Ausgabekanäle hinzukommen.

Auf jeden Fall sollte man ein decoupled CMS inklusive seiner Rendering-Engine einsetzen, wenn man:

• eine Website braucht (also HTML-Ausgabe im Browser)
• viel Traffic erwartet
• eine Website mit standardisierten Inhalten betreibt, die gecached werden können
• die Inhalte über eine API auf andere Geräte ausgeben werden

Ein Headless-CMS oder ein decoupled CMS mit einem Headless-only-Setup ist angebracht, wenn:

• Inhalte hochdynamisch sind und sich nur schwer cachen lassen
• man ein vorhandenes Frontend einsetzt, das Daten aus vielen verschiedenen Quellen zusammenführt
• man gar keine Website benötigt (z. B. wenn man Inhalte nur für eine mobile App bereitstellen möchte)

Meiner Erfahrung nach benötigen die meisten CMS-Projekte auch heute noch ein Web-Frontend. Ist dies der Fall, sollte man es sich gut überlegen, bevor man auf eine integrierte Rendering-Engine verzichtet. Sulu hat eine Rendering-Engine inkludiert und ist decoupled, damit hält man sich die Optionen für zukünftige Headless- und andere Anwendungsfälle offen.

Wir haben mit Sulu eine Reihe von rein Headless-Lösungen implementiert. Hier sind einige Beispiele für Situationen, in denen der reine Headless- oder Hybrid-Modus für unsere Kunden gut funktioniert hat:

• Ein Intranet für ein großes international tätiges Unternehmen. Dies ist ein gutes Beispiel für ein Projekt, in dem Inhalte auf einzelne Personengruppen zugeschnitten werden: nach diversen Kriterien wie zum Beispiel Abteilung, Region und Sprache. Wir haben Sulu als Headless-Backend eingesetzt und ReactJS für das Frontend verwendet.
• Integration von Inhalten in ein bestehendes Setup. Sulu stellt das Content-Repository für die Website eines Betreibers für Online-Spiele bereit. Konkret basiert die Website, auf der auch die Spiele eingebettet sind, auf einem komplexen NodeJS-Stack, der Inhalte und Daten für die Spiele aus den unterschiedlichsten Quellen bezieht. Ihr bestehendes Frontend fungierte als zentrale Rendering-Engine für alle Anfragen.
• Online Tauschbörse für Sammelsticker und Trading Cards. Wir durften eine Web-Applikation für eine Community zum Tausch von Aufklebern und Sammelkarten entwickelt. Sulu CMS Rendering-Engine liefert zunächst die Frontend-Anwendung in HTML aus. Dann läuft die Website „headless“ und liefert personalisierte Informationen an angemeldete Benutzer. Es gibt auch viele öffentliche Seiten, wie z. B. Nachrichten oder FAQs. Die Rendering-Engine liefert diese aus und speichert sie im Cache.

Empfehlung 3: Verwendung eines Frameworks wie Symfony

Es wird viel darüber geredet, das Frontend vom Backend zu befreien. Aber wie wäre es, die Geschäftslogik vom CMS zu befreien? Dieser Ansatz nennen wir „bring your own entity“. Da Sulu auf Symfony basiert, kannst man all seine Entitäten und deren benutzerdefinierte Business Logic unter eine einheitliche Benutzeroberfläche vereinen. Ein Rezepte-Portal könnte Entitäten für Zutaten, Rezepte, Veranstaltungen, Tickets und Community Members erfordern. Dies ist ein idealer Anwendungsfall für Symfony und damit auch für Sulu. Ein anderes CMS mag headless oder decoupled sein, aber wenn es nur begrenzte Arten von Entitäten und Geschäftslogik abbilden kann, könnte es sein, dass man seine Inhalte früher als erhofft woanders hin migrieren muss.

Headless ist Teil der sich weiterentwickelnden Content-Management-Landschaft

Herkömmliche CMS wurden dafür gedacht, Inhalte in einem Browser zu bearbeiten und diese in einem Browser darzustellen. Sie wurden nicht für unsere heutige Realität konzipiert, in der Inhalte genauso gut auf einer Uhr oder in einer Webanwendung angezeigt werden können. Wenn neuartige Anwendungen Live-Daten von Online-Spielen aus unterschiedlichen Datenquellen mit Inhalten von Redaktionssystemen kombinieren müssen, brauchen wir neue Ansätze.

Mit der Ausgabe von Content über eine API und dem Verzicht auf einer Ausgabeschicht, gingen Headless-Only-CMSs neue Wege und waren wichtige Impulsgeber für den CMS-Markt. Dennoch brauchen wir für viele Projekte immer noch Websites, die unter hoher Last mit leistungsstarkem Caching und Bildoptimierung funktionieren. Deshalb bietet die decoupled CMS-Architektur heute die beste Lösung. Sie bietet eine Möglichkeit, strukturierte Inhalte über eine agnostische API verfügbar zu machen, liefert aber auch eine Rendering-Engine und eine Präsentationsschicht für eine der häufigsten Anwendungsfälle: rasend schnelle, robuste Webauftritte.