Decoupled CMS – ist „Headless“ die Zukunft oder nur ein weiteres Buzz Word?

01. Dezember 2016 von Martin Wiederkehr Veröffentlicht unter Digitale Transformation, Know-how/Tipps&Tricks, TYPO3 Website, Intranet & Extensions Verschlagwortet mit , , , , ,

In der letzten Zeit hört man immer wieder von Headless oder Decoupled CMS, doch was ist damit überhaupt gemeint?

Traditionellerweise funktionieren die meisten Content Management Systeme (TYPO3, Drupal und wie sie alle heissen) so, dass dasselbe System sowohl für die Redaktions- und Administrationsoberfläche zuständig ist wie auch gleichzeitig die Frontendausgabe übernimmt.

Bei einem Decoupled CMS werden diese Aufgaben nun auf unterschiedliche Systeme aufgeteilt. Das eigentliche CMS wird kopflos, was nichts anderes heisst, als dass die Inhaltsverwaltung weiterhin über das CMS abgedeckt wird. Die Ausgabe der Daten erfolgt aber über eine andere Applikation, beispielsweise über einer auf JavaScript basierten Frontend-App. Die verwendete Technologie spielt dabei eine weniger wichtige Rolle. Die zur Verfügung gestellten Daten können in völlig unterschiedlichem Kontext verwendet werden und das ist genau der Clou an der Sache.

Die Vorteile eines Decoupled CMS

Aus der verwendeten Architektur ergeben sich diverse Vorteile für den Kunden sowie für den Hersteller:

  • Wegfall einer monolithischen Architektur: Einzelkomponenten können über die Zeit einfach ausgetauscht werden. Dies ermöglicht über die Laufzeit eine Kostenersparnis und erhöht massgeblich die Zukunftssicherheit der Lösung.
  • Hohe Skalierbarkeit und (Geo-)Redundanz
  • Durch die saubere Aufteilung der Komponenten ist es im konkreten Fall möglich, die API Konnektoren wiederum auf mehrere Systeme zu verteilen. Dies ermöglicht es beispielsweise, pro Schnittstelle eine eigene Konnektor-Instanz laufen zu lassen um Quereffekte bei Lastspitzen einzelner API Abfragen zu umgehen.
  • Die Trennung von Backend und Frontend ermöglicht eine effiziente Zusammenarbeit mit Dritten (zum Beispiel einer auf Frontend-Apps spezialisierten Agentur) und den Einsatz von deren bevorzugter Technologie.
  • Die freie Wahl einzelner Komponenten ermöglicht einen optimalen Technologiestack für einzelne Teilaufgaben, beispielsweise Authentifizierungsservices.

Für wen eignet sich diese Architektur?

Trotz der offensichtlichen Vorteile eignet sich eine auf dem Headless-Prinzip basierten Architektur nicht für jeden Kunden. Auf die Nachteile gehen wir gleich noch detaillierter ein. Grundsätzlich sehen wir aktuell, dass das Prinzip in folgenden drei Einsatzszenarien seine Stärken ausspielen kann:

  • Umfangreicher Einsatz von mehreren Datenquellen und Fremdsystemen
  • Hohe Anforderungen an die Skalierbarkeit
  • Zusammenarbeit mit einer externen Frontend Agentur

Die Nachteile

Es ergeben sich durch die Architektur aber auch gewisse Nachteile, über welche man sich im Vornherein im Klaren sein sollte. Es handelt sich hierbei nicht nur um technische Hindernisse. Teilweise fehlen auch einfach Basisfunktionalitäten, welche wir von bestehenden Lösungen gewohnt sind.

  • Die Out-of-the-Box Funktionalität eines CMS kann vielfach nicht 1:1 verwendet werden. Dies bedeutet: einen erhöhten Initialaufwand, auch für vermeintlich einfache Funktionen.
  • Durch die Verteilung der Architektur auf diverse Einzelkomponenten ist die Einstiegshürde beim Hosting/Betrieb gegenüber einer klassischen Architektur höher. Dies schlägt sich auch in den entsprechenden Kosten nieder.
  • Die Anforderungen an Projektmitarbeiter fallen gegebenenfalls höher aus, da mehrere unterschiedliche Technologien im Einsatz sind.

Mit der Zeit wiegen gewisse Nachteile – wie beispielsweise das Fehlen von Out-of-the-Box Funktionalität – sicherlich weniger stark, da man auf ein Set von bereits umgesetzten Funktionalitäten zurückgreifen kann.

Decoupled CMS @snowflake

AnhandDecoupled CMS eines aktuell in der Umsetzung befindlichen Projektes, möchten wir einen möglichen Technologiestack vorstellen. Im konkreten Fall haben vor allem die hohe Anzahl an aktuell und potentiell angebunden APIs sowie die Zusammenarbeit mit einer spezialisierten Frontend Agentur auf unsere Entscheidung eingezahlt.

TYPO3 Backend

Als CMS kommt hierbei TYPO3 zum Einsatz. Nun ist TYPO3 vielleicht kein klassisches Decoupled CMS, aber niemand hat behauptet, dass man die entsprechenden Anpassungen nicht vornehmen kann. Die Wahl von TYPO3 zeigt sogar beispielhaft die Eleganz dieser Architektur: Der Kunde hatte nämlich bereits früher TYPO3 im Einsatz und kann durch die weitere Verwendung von TYPO3 bei der Schulung von hunderten Redakteuren massiv Kosten einsparen und auf eine grössere Akzeptanz zählen.

In diesem Case dient TYPO3 der Erfassung von statischen Inhalten sowie der Konfiguration der Ausgabe von Daten aus Drittsystemen. Beispielsweise kann innerhalb von TYPO3 eine Projektansicht für das Frontend konfiguriert werden, welche nur Projekte einer bestimmten Kategorie ausgibt. Die effektiven Daten der Projekte und deren Kategoriezuweisung kommt dabei via Webschnittstelle aus einer externen Projektdatenbank.

Technisch gesehen ist für uns TYPO3 neben den restlichen „klassischen“ Schnittstellen ebenfalls ein solcher Datenlieferant. Sämtliche Schnittstellendaten werden mittels Symfony basierend auf API Konnektoren in eine zentrale Elasticsearch zur Datenhaltung eingespielt.

Obwohl Elasticsearch ebenfalls eine rudimentäre Möglichkeit zur Assetverwaltung bieten würde, haben wir auf einen eigenen Storageserver gesetzt. Dieser übernimmt zusäzlich das Skalieren auf unterschiedliche Bildgrössen für eine responsive Bilddarstellung sowie andere für das Frontend wichtige Bildbearbeitungen. Als Technologie kommt hierbei Node.js und Nginx zum Einsatz, welche das einfache Parallelisieren und Pipen der Berechnungen ermöglicht.

Searchdriven Frontend

Sämtliche Daten stehen nun also in der Elasticsearch in einer „normalisierten“ Form zur Verfügung und können daher dank einer durchdachten Datenarchitektur einfach nach unterschiedlichsten Kriterien durchsucht und facettiert werden. So kann man einfach dargestellt sagen: Das Frontend – basierend auf Node.jsKnockback.js und Handlebars – setzt bei jedem Aufruf eine Suche ab und stellt sie in einer vordefinierten Form dar.

Und hier schliesst sich der Kreis zum TYPO3 Backend und der Schnittstellen-Konfiguration: Die Konfiguration für die Ausgabe von API Daten wird als Suchabfrage an das Frontend geliefert, welches dann eine entsprechende Abfrage an die Elasticsearch absetzt. Die klassische Suche über das Suchfeld der Seite ist also technisch gesehen genau dasselbe.

Hierdurch ergeben sich einige spannende Use Cases und Spielereien: Stellen Sie sich vor, Sie befinden sich auf einer klassisch anmutenden Website und fangen an, im Suchfeld nach einem Begriff zu suchen. In Echtzeit werden nun die Inhalte auf der Website neu arrangiert oder nachgeladen, ausgeblendet oder hervorgehoben.

Performance und Sicherheit

Zugegebenermassen stellt diese Architektur auch erhöhte Anforderungen an die Performance und Sicherheit. Aus diesem Grund setzten wir auf einen auf Varnish und Nginx mit Naxsi und SPDY basierenden Reverse-Proxy.

Dieser übernimmt einerseits die Funktion einer Firewall, indem er sämtliche eingesetzten Komponenten vom Internet abtrennt und Zugriffe IP-basiert nur auf die benötigen Ressourcen ermöglicht. Andererseits setzen wir ihn auch für In-Memory Caching ein, um häufige Abfragen gar nicht erst an die rechenintensiveren Komponenten weiterreichen zu müssen.

Genau das brauchen wir!

Nichts anderes wollten wir mit diesem Blogpost erreichen. Das tönt nicht nur hochinteressant, genau das ist es auch!

Lassen Sie sich von uns zum Thema Decoupled CMS beraten. Wir zeigen wir Ihnen gerne in einem persönlichen Gespräch die Möglichkeiten und Chancen dieser Architektur für Ihren Use Case auf.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

4 Gedanken zu “Decoupled CMS – ist „Headless“ die Zukunft oder nur ein weiteres Buzz Word?

  1. Pingback: Decoupled CMS – ist „Headless“ die Zukunft oder nur ein weiteres Buzz Word? - zend-framework.net

    • Hy Sascha
      Grundsätzlich hast du Recht damit, dass (Geo-)Redundanz kein Alleinstellungsmerkmal eines headless CMS an sich ist, sondern auch mit klassischen CMS realisierbar ist.
      Trotzdem bietet die im Post erwähnte Architektur einige Vorteile in diesem Zusammenhang, welche ich gerne kurz erläutere.

      Eines der Hauptprobleme im Zusammenhang mit redundanten Systemen ist es, konsistente Schreibvorgänge zu erreichen. Wenn man die CMS-Komponente für sich genommen betrachtet (im beschriebenen System also das „Backend mit REST-API“), birgt ein headless CMS genau die selben Herausforderungen wie ein klassisches, Redundanz muss also genau gleich gelöst werden.

      Wenn man sich allerdings das Frontend anschaut, werden die Vorteile rasch ersichtlich.
      Ein headless CMS zwingt dich dazu, eine saubere Trennung von Frontend und Backend zu machen. Wenn du dich dabei bei der Schnittstellen-Definition an die Vorschriften von REST hältst, ist es ein leichtes, alle lesenden Zugriffe von redundanten Systemen beantworten zu lassen. Im Optimalfall kannst du das System komplett nach dem CQRS-Gedankenmodell aufbauen, wobei die Skalierung und Geo-Verteilung der für den Lesezugriff zuständigen Systemteile sehr einfach ist.

      In der beschriebenen Lösung ist es dank einer Zwischenschicht basierend auf einer NoSQL Datenbank (Elasticsearch) ausserdem sehr einfach, diesen Datenspeicher zu skalieren, denn das zugrunde liegende System unterstützt dies bereits „von Hause aus“. Das ist insofern ein Vorteil, als dass dieser Datenspeicher der einzige ist, welcher von Besuchern der Webseite abgefragt wird und er somit den Löwenanteil an Requests beantworten muss.

      Für die Schreibzugriffe auf diesen Zwischenspeicher konnten wir ausserdem dank der Architektur ohne Weiteres bei Rechenintensiven Quellen (z.B. Bildprozessierung) von einem synchronen auf ein Queue-basiertes System wechseln, was eine horizontale Lastverteilung ebenfalls wesentlich erleichtert.

      Zusammenfassend kann man sagen, dass ein headless CMS an sich keine unmittelbaren signifikanten Vorteile hinsichtlich (Geo-)Redundanz bietet, aber es erleichtert den Software Ingenieuren die Arbeit erheblich, ein System aufzubauen, welches diesbezüglich entscheidend mehr Potential aufweist.

      Ich hoffe, ich konnte deine Frage beantworten und führe gerne noch weitere Details aus, falls ich das noch nicht geschafft habe 😉

      Grüsse und ein schönes Wochenende,
      Christoph