NEU: Unsere Online UX/UI-Kurse im Jänner und Februar 2021

Jetzt anmelden!
Close

Headless CMS: eine Einführung

Headless CMS Lösungen sind in den letzten Jahren immer wieder als Trend hervorgetreten. Hier wollen wir mit dem Thema etwas aufräumen und euch die wichtigsten Unterschiede zu klassischen Systemen etwas näherbringen.

3. Dezember 2020, von Fabian
I

In den letzten Jahren ist in der Webentwicklung ein Trend immer wieder besonders hervorgestochen: Headless CMS. Da uns bei Liechtenecker solche Veränderungen natürlich auch beschäftigen, möchte ich im heutigen Blog eine kurze Einführung in die Thematik bieten und im Weiteren versuchen unseren Standpunkt zu dem Thema darzulegen.

Was ist ein Headless CMS?

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.

Warum sollte man nun Headless CMS statt einem monolithischen CMS 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:

  • Anbindung mehrerer Frontends 
  • Mehr Flexibilität für Frontend Developer (hinsichtlich Programmiersprachen etc.)
  • Die Time-to-market kann reduziert werden, weil die Content-Creators zeitgleich mit der Entwicklung des Frontends beginnen können
  • Die Benutzung des Headless CMS ist für Redakteure einfacher, da es weniger Funktionen gibt und das System daher weniger komplex ist
  • Bessere Skalierbarkeit, Performance und Sicherheitsvorteile das Headless CMS oft SaaS-Lösungen sind 

Natürlich gibt es aber dennoch auch einige Nachteile:

  • Höherer Aufwand, da kein fertiges Frontend mitgeliefert werden
  • Mehr Knowhow im Frontend erforderlich, da von Grund auf entwickelt werden muss
  • Keine Vorschau-Funktion für die Redakteure

Haben nicht System wie Drupal oder WordPress mittlerweile auch REST-Schnittstellen?

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!

Fabian Schiel

Meine Rolle bei Liechtenecker: Backend-Dev Wenn es weder IT noch Digitalisierung gäbe, wäre mein Beruf: Nomadisch lebender Philosoph Mein Herz schlägt für: Hummus, Dune, Delay-Effektgeräte
1 Kommentar.
Kommentar verfassen
Name
Mail
Web
Captcha
Erfolgreich!
Fehler!
16. Dezember 2020 um 08:29

Ich kann Storyblok (https://www.storyblok.com/) stark emfehlen. Headless CMS made in Austria

Jetzt antworten
Antwort verfassen
Name
Mail
Web
Captcha
Erfolgreich!
Fehler!
Dockerize Drupal 9
Technologie – Blogbeitrag

Dockerize Drupal 9

13. Januar 2021, von Daniel

Der heutige Blogartikel wird etwas technischer als gewöhnlich, denn heute geht’s darum, Drupal 9 als Container-Anwendung bereitzustellen. Der Artikel gilt für Drupal 9 wie auch für Drupal 8.

Jetzt lesen
Liechtenecker Leseliste #62 mit Susanne Liechtenecker
Inspiration – Podcasts

Folge #62 mit Susanne Liechtenecker

27. November 2020

In Folge 62 besinnt sich Susanne auf die Anfänge dieses Podcasts und begrüßt keinen Gast, sondern erzählt über das Buch "Jäger, Hirten, Kritiker" von Richard David Precht und warum es sie inspiriert hat.

Jetzt anhören
Close