Headless CMS: eine Einführung

Um diese Frage aufzuklären, möchte ich zunächst ein bisschen erläutern was ein klassisches CMS eigentlich macht. Ein klassisches CMS wird auch monolithisch genannt und zwar aus dem Grund, weil es alle Funktionen, die es beinhaltet, zusammenhängend in einem Kernsystem hat. Inhalte werden also üblicherweise so erstellt, dass ein Redakteur den Content über eine Administrationsoberfläche relativ fertig formatiert an ein Backend übergibt, welches die Inhalte in dieser Form auch in der Datenbank speichert. Das hat zur Folge, dass die Darstellung der Inhalte ab diesem Zeitpunkt schon relativ fix ist und nicht mehr großartig verändert werden kann.

Ein Headless CMS geht nun einen anderen Weg indem es die Inhalte, welche das Backend übergeben bekommt in einer Art “Reinform” abspeichert, welche keine Formatierungen und Layoutinformationen beinhaltet, sondern lediglich die Inhalte an sich. Zusätzlich stellt das Headless CMS nun eine Schnittstelle zur Verfügung, über die die Inhalte abgerufen werden können. Dabei handelt sich üblicherweise um ein Rest-API, es gibt aber auch bereits einige Systeme am Markt die die neue Abfragesprache GraphQL verwenden.

Ein Headless CMS hat gegenüber dem klassischen CMS einige Vorteile. Der Naheliegendste und aus meiner Sicht auch Wichtigste ist dabei die Multichannel-Fähigkeit bzw. die Möglichkeit mehrere verschiedene Frontends anzubinden. 

Hier eine Übersicht über einige Vorteile gegenüber dem klassischen CMS:

Natürlich gibt es aber dennoch auch einige Nachteile:

Natürlich ist der Headless-Trend auch nicht spurlos an den monolithischen CMS-Lösungen vorübergegangen. So wurden Systeme wie WordPress oder Drupal in den letzten Jahren auch um (REST-)APIs erweitert, an die nun zusätzliche Frontend Apps angehängt werden können. Im Gegensatz zu Headless CMS Lösungen sind die Systeme damit zwar noch immer nicht “API-first” entwickelt, aber sie nähern sich dabei immer mehr einem Hybrid CMS oder DECOUPLED CMS an.

Was ist ein Hybrid CMS bzw. ein Decoupled CMS?

Ein Hybrid CMS versucht zwischen dem klassischen “Page-driven” Ansatz und dem neueren “API-driven” Ansatz gewissermaßen einen Mittelweg zu gehen. Es bietet hierfür unter anderem Editoren und Vorschau-Funktionen an, die es Redakteuren ermöglichen mehr Einfluss auf die Darstellung ihrer Inhalte zu nehmen. Die Inhalte werden also hier meist formatiert gespeichert, womit eine saubere Trennung zwischen Backend und Frontend nicht mehr gegeben ist. Dennoch gibt es in einem Hybrid CMS auch eine Schnittstelle, über welche die Inhalte abgerufen werden können. Somit kann auch eine zusätzliche Frontend-App angehängt werden. Der Entwicklungsaufwand im Frontend ist dabei aber vermutlich meist eine Spur höher, da die Inhalte nicht einer solchen “Rohform” vorliegen, wie in einem Headless CMS. Ich denke es lässt sich sagen dass sowohl Drupal als auch WordPress in den letzten Jahren beide diese Richtung eingeschlagen haben.

Ein Decoupled CMS auf der anderen Seite ist nun eines, das die Trennung zwischen Frontend und Backend strikt einhält und im Gegensatz zum Headless CMS dennoch ein Frontend als Teil des Systems inkludiert hat. Es kann also Entwicklungsaufwand gespart werden, indem auf das Frontend vom CMS zurückgegriffen wird und gleichzeitig können alle Vorteile der Headless-Architektur ausgespielt werden. Auf der anderen Seite kommen aber die Nachteile dieser Architektur ebenso zum Tragen und zwar in erster Linie hinsichtlich der Redakteure, welche nun weniger Einfluss auf die Darstellung der Inhalte haben. 

Welches CMS sollte man nun also wählen?

Die Antwort, die wir für uns gefunden haben, mag etwas unbefriedigend erscheinen, aber ich denke sie liegt auf der Hand: es kommt auf das Projekt an. 

Bei großen Websites, welche in erster Linie auf Endgeräten mit größeren Screens dargestellt werden sollen, wird die Wahl denke ich noch immer auf die klassische Variante bzw. ein Hybrid CMS fallen. Diese Systeme haben sich für diese Zwecke einfach schon seit längerem bewährt und bieten für die Redakteure der Seite einige Mittel um Inhalte nach ihren Vorstellungen anzupassen. Eine Abstimmung mit den Developern für jedes kleine Layout-Detail ist somit also nicht notwendig. Sollte dann noch zusätzliche eine App angehängt werden kann dank Entwicklungen in Richtung Hybrid CMS noch immer auf eine API zurückgegriffen werden. 

Bei ganzen Portalen bzw. Plattformen welche von Vornherein darauf konzipiert sind Inhalte auf vielen verschiedenen Kanälen auszuliefern, also auch solchen welche nicht mit Webtechnologie entwickelt werden (native Mobile-Apps, Infoscreens, IoT-Geräte, etc.) sieht die Sache aber schon anders aus. Hier macht eine Headless- bzw. Decoupled-Architektur natürlich absolut Sinn, da es bei solch verschiedenen Frontend-Apps deutlich einfacher ist die Daten in “Rohform” zu bekommen.

Wichtig ist am Ende des Tages vor allem das eine gute Abstimmung mit dem Kunden stattfindet, in der die Vorstellungen und Prioritäten herausgearbeitet werden, um so eine vernünftige Entscheidung über die Wahl des CMS treffen zu können.

Ich hoffe ihr konntet aus diesem Beitrag zu Headless CMS etwas für euch mitnehmen. Schreibt mir eure Fragen und Anmerkungen gerne in die Kommentare!