Digital First: Loading

‘Headless’
ist
nicht
kopflos
neue
Wege
im
CMS

Headless CMS

Content Management Systeme beschäftigen mich seit Beginn meiner Berufstätigkeit. Lange Zeit war der traditionelle Ansatz – nämlich eine Codebasis für alle Funktionalitäten, Browser und Apps – meine Heimat. Doch die Anforderungen ans CMS werden komplexer und so hat sich “headless-CMS” in meinem Arbeitsalltag etabliert.

Traditionell und bewährt: die monolithische Codebasis

Ich habe bei Eigenentwicklungen meiner jeweiligen Arbeitgeber wie etwa Digitalworkroom, Sulu mitgewirkt – und genauso habe ich auch an Weiterentwicklungen auf Basis bekannter Systeme wie Drupal, WordPress, spunQ und dergleichen mitgearbeitet. So verschieden die Ansätze dieser Arbeiten waren, zwei Punkte waren immer gleich:
 
  1. Die Programmiersprache PHP
  2. Tendenziell monolithische Systeme
     
Vom Backend für die Redakteure über Import- und Export-Funktionalitäten bis zum Frontend für Browser oder APIs für Apps – es entspringt alles einer gemeinsamen Codebasis. Zudem läuft all das meist auf denselben, vom Kunden gehosteten und gewarteten, Maschinen. Wir sprechen vom traditionellen Ansatz.

Neue Anforderungen verlangen andere Wege

Die Zeit bleibt bekanntlich nicht stehen, schon gar nicht in der Welt des Programmierens. Es gibt viele Neuerungen und Anforderungen zu berücksichtigen:

  • kostengünstige und hochverfügbare Cloud-Speicher
  • APIs für Zusatzfunktionen
  • eine Vielzahl neuer Endgeräte
  • die Möglichkeit zur Datenverarbeitung durch Drittanbieter
  • die automatische Bespielung von Social-Media-Plattformen

Wie werden wir diesen Anforderungen gerecht? Die Antwort heißt headless-CMS.

Headless-CMS macht Vieles möglich

In einer solchen Architektur übernimmt das CMS nur mehr die Aufgabe, Inhalte – wie Artikel, Produkte, Bilder – zur Verfügung zu stellen. Der Zugriff erfolgt über, zumeist JSON-basierte APIs, auch bekannt als Content APIs.

Daraus ergibt sich, dass das Frontend komplett entkoppelt ist und eigenständig Inhalte rendert. Was früher eingebettete Twig-Templates waren, sind heute eigenständige React-Anwendungen.

Auf diese APIs können in Folge aber auch Drittanbieter und Apps zugreifen. Selbst eine Schnittstelle zu Geräten und Services des IoT (internet of things) ist denkbar, um zum Beispiel die Paketverfolgung der Bestellungen eines Online-Shops zu integrieren. Aus dem alten, einfachen Content Management System wird so rasch ein Data Management Center.

Die Skizze verdeutlicht die Unterschiede der zwei Ansätze:

CMS vs Headless CMS
BU: Die Unterschiede zwischen den zwei Ansätzen ergeben sich unter anderem durch die Anzahl der Komponenten.

Zwei Nachteile des headless-Ansatzes stehen vielen Vorteilen gegenüber.

Die Nachteile:

  • Mehr Komponenten: Das gesamte System wird eine Spur komplexer, da mehr Komponenten im Spiel sind: EFS (editor facing side), also das altbekannte Backend, CFS (client facing side), das eigentliche Frontend und natürlich die APIs an sich.
  • Mehr Komplexität: Mehr Komplexität ergibt sich daraus, dass einige Funktionalitäten wie etwa Formulargeneratoren – die in Systemen wie Drupal, Wordpress etc. bereits enthalten sind – im CFS/EFS nachgebildet werden müssen.

Die Vorteile:

  • Klare Grenzen: Jede Komponente hat klare Aufgaben. Diese können leichter von verschiedenen Personen, Teams oder sogar externen Unternehmen weiterentwickelt werden.
  • Zukunftssicher: Schnittstellen zu neuen Devices und Services ändern sich schneller und mit höherer Wahrscheinlichkeit als die Kernfunktionen selbst. Durch die genauere Trennung kann man auch in Zukunft schneller und kostengünstiger (re)agieren.
  • Sicherheit: Über die APIs lässt sich klar regeln, wer wo wann was darf. Im Fehlerfall oder bei einem Angriff könnte zum Beispiel das CFS deaktiviert werden, ohne den Betrieb des EFS zu stören.
  • Skalierbarkeit: Liegt das CFS beispielsweise in einem dynamischen Cloud-Service, lässt sich per Mausklick ein weitere Instanz online bringen und es können mehr Zugriffe bearbeitet werden. Wer genau hinsieht erkennt, dass man vor und hinter der API mittels weiterer Server jederzeit ein Mehr an Leistung erreichen kann.
  • Erweiterbarkeit: Die Erweiterungen der API für neue Anforderungen, wie etwa neue Apps, sind oft schneller und einfacher in einigen separaten Modulen erledigt, als in einer monolithischen Code-Basis.
 

Die Vorteile überwiegen also klar gegenüber den Nachteilen. Die stärkere Fokussierung und das Ausnutzen modernen Architekturen und Technologien bringt mehr Stabilität und Flexibilität.

Diskutieren Sie mit uns auf Facebook und Twitter . Natürlich freuen wir uns auch über ein E-Mail von Ihnen.

Mehr Blogartikel zum Thema:

loading
Nach oben
 

Hallo!
Sie möchten mit uns zusammenarbeiten? 

Welche Themen sind für Sie interessant?

ICH

Erzählen Sie uns doch bitte ganz kurz worum es geht.

ICH

Gerne würden wir mehr darüber erfahren! Wie dürfen wir Sie denn kontaktieren?

Wie dürfen wir Sie denn kontaktieren?


ICH

An welche Addresse sollen wir die Mail schicken?

Unter welcher Nummer sind Sie am besten erreichbar?

Leider sind zur Zeit alle MASSIVE DOVES auf Urlaub ;) Wollen Sie uns alternativ vielleicht eine Telefonnummer oder E-Mail Adresse hinterlassen, unter der Sie erreichbar sind?

ICH

Bitte geben Sie eine gültige E-mail Adresse ein.


Verraten Sie uns noch Ihren Namen?

ICH

Zum Schluss noch etwas Bürokratie #DSGVO:

Vielen Dank für Ihre Anfrage! Wir werden uns so rasch wie möglich bei Ihnen melden.

Es ist etwas schiefgelaufen.
Bitte lade die Seite neu und versuch es noch einmal.