Decoupled CMS - ist "Headless" die Zukunft oder nur ein weiteres Buzz Word?

Decoupled CMS - ist "Headless" die Zukunft oder nur ein weiteres Buzz Word?

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.

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.js, Knockback.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.