Tipps und Tricks für hybride Headless-CMS-Lösungen

Hybrid-Headless: 4 Wege zur modernen CMS-Lösung
Keine Kommentare

Headless CMS sind praktisch, haben aber auch Nachteile. Hybride Lösungen, die sowohl mit einer Headless-Lösung als auch mit einem klassischen Seiteneditor arbeiten, sind die nächste Stufe der Evolution.

Ein Headless-CMS-Ansatz hat viele Vorteile: Die Möglichkeit, Inhalte von der Präsentation zu entkoppeln, Neuerungen mithilfe mobiler Apps und der neuen Generation von Frontend-Frameworks einzuführen, und vor allem die Möglichkeit, sofort loslegen zu können. Ihm sind jedoch auch Grenzen gesetzt. Ein Problem ist, dass Vermarkter und Inhaltsersteller von Entwicklern abhängig werden. Sie sind auf die Eingabe von Inhalten in strukturierte Formulare beschränkt und die Erstellung von Rich Content ist nicht möglich. Ein weiteres Problem besteht darin, dass ein reines Headless CMS einige wesentliche Anforderungen an das Content Management nicht abdeckt. Dies gilt insbesondere für Enterprise-Features wie Personalisierung, konfigurierbaren Workflow, Authentifizierung und Zugriffskontrolle.

Ein Hybrid-Headless-Ansatz vereint das Beste aus beiden Welten: sauber strukturierter Inhalt plus ein großartiges Autorenwerkzeug für mehr Kreativität und Flexibilität.

Ich werde vier Hybrid-Headless-Techniken skizzieren, die es Entwicklern und Vermarktern ermöglichen, jegliche Inhalte gemäß der entsprechenden Anforderung einfacher und schneller zu erstellen und über jeden Kanal auszuliefern. Alle vier Techniken konzentrieren sich auf das Zusammenspiel der Content-Bereitstellung über REST per Headless CMS mit der voll ausgestatteten UX eines vollständigen CMS.

Die User Experience eines vollständigen CMS

Was ist so toll an dieser UX? Sie befähigt Nicht-Entwickler, Schlüsselaufgaben der Website selbst auszuführen. Natürlich sind alle CMS unterschiedlich, aber es gibt zwei Werkzeuge, die in den meisten vollständigen CMS auf ähnliche Weise genutzt werden: Die Sitemap (oder Page Tree) ermöglicht es Ihnen, die Struktur Ihres gesamten Projektes zu überblicken, typischerweise als hierarchische Darstellung mit der Homepage an der Spitze. Der Seiteneditor (auch bekannt als Page-Editor, Page-Builder, WYSIWYG-Editor, Post-Editor) erlaubt Ihnen, eine Seite zu erstellen und zu bearbeiten: Wählen Sie eine Vorlage für die Seite, ändern Sie das Layout, verschieben Sie Komponenten per Drag&Drop und füllen Sie die Seite mit Inhalten, die in Ihrem CMS gespeichert sind. Obwohl dieses Werkzeug immer noch als „Seiteneditor“ bezeichnet wird, wäre heutzutage der Begriff „Experience-Editor“ angebrachter – hier können Sie wirklich ein Nutzererlebnis erzeugen und mehr als nur Inhaltsdaten in ein Formular eingeben.

Die vier wichtigsten Hybrid-Headless-Techniken

Vollständiges CMS und REST API

Erstellen Sie saubere, von der Präsentation unabhängige Inhalte. Der Inhalt wird sowohl über eine Website mit Page Tree und Editor als auch per REST Endpoints ausgeliefert.

Angetrieben durch die Popularität von mobilen Apps, Frontend-JavaScript-Frameworks und Serviceorientierter Architektur (SOA), nutzen viele Unternehmen diese grundlegende Technik bereits. Vermarkter und Content-Ersteller sind autark und haben volle Freiheit bei der Erstellung und Verwaltung der Inhalte der Website. Derweil können Entwickler mit dem REST-API mit ihren Programmiersprachen und den Frameworks ihrer Wahl Mobile- und Frontend-Apps erstellen oder den Inhalt durch vorhandene Lieferpipelines oder über Drittanbietersysteme leiten.

Seitenfragmente als JSON

Vermarkter verwenden den Seiteneditor, um ein Fragment einer Seite inhaltlich und mit spezifischen Vorlagen redaktionell zu bearbeiten. Entwickler ziehen im JSON-Format nur den reinen Inhalt aus diesem Fragment heraus und rendern ihn in ihrer App.

Der Vorteil dieses Ansatzes besteht darin, dass Vermarkter nicht nur ihre eigene Website gestalten können, sondern auch Nutzererlebnisse, die in Apps und anderen Systemen genutzt werden. Und sie können es mit vertrauten Werkzeugen tun, bis hin zur Möglichkeit, die Personalisierungs- und Zielgruppen-Adressierungs-Funktionen des CMS zu nutzen.

Da Entwickler Inhalte direkt als JSON beziehen, können sie diese im Headless-Mode nach Belieben verwenden. Die Entwickler haben die Kontrolle über die tatsächliche Anzeige des Inhalts, sodass die Ausgabe anders aussehen kann als im Seiteneditor.

Seitenfragmente als HTML

Wie oben beschrieben, verwenden Vermarkter den Seiteneditor, um ein Fragment einer Seite inhaltlich und mit spezifischen Vorlagen redaktionell zu bearbeiten. Der Entwickler konfiguriert ein anderes System oder eine App, um dieses Fragment herauszuziehen, das vom CMS als HTML gerendert wurde. Dies ist vergleichbar mit der vorhergehenden Technik, liefert aber gerendertes HTML anstelle von JSON.

Quelle: https://blogs.magnolia-cms.com/christopher-zimmermann/detail~&hybrid-headless-cms~.html

Nun könnten Sie aber fragen: „Moment mal, was ist mit einer REST-API? Wie sieht es mit der Präsentationsunabhängigkeit aus?. Sie haben mich erwischt! Das ist in dieser Liste relevant, weil es immer noch um eine andere App oder ein anderes Auslieferungssystem geht, das sich Inhalte aus dem CMS greift.

Wie zuvor erzeugt der Vermarkter Nutzererlebnisse, die in Apps und anderen Systemen verwendet werden, mit vertrauten Werkzeugen. In dieser Technik, da gerendertes HTML ausgegeben wird, hat der Vermarkter auch eine WYSIWYG-Authoring-Experience mit Live-Vorschau des Inhalts.

Erstellen von Frontend-Apps

Entwickler entwerfen ihre Frontend-Apps mit einer modernen komponentenbasierten Architektur. Vermarkter verwenden den Seiteneditor zur Inhaltsverwaltung, Konfiguration und Zusammenstellung von Frontend-JavaScript-Anwendungen (auch bekannt als SPA: Single Page Application).

Die ersten drei Techniken können alle verwendet werden, um den Inhalt der Frontend-Apps zu verwalten. Diese Technik geht darüber hinaus.

Mit diesem Ansatz können Vermarkter tatsächlich eine Frontend-App erstellen – auf die gleiche Art und Weise, die sie von der Erstellung einer Website bereits gewohnt sind.

Das hat enormes Potential, da sich Frameworks wie React, Angular und Vue sehr dynamisch entwickeln. Wir haben eine Menge Kunden, die diese Frameworks lieben, aber mit der Frage kämpfen, wie sie ihren nicht-technischen Mitarbeitern eine Möglichkeit geben können, ihre Aufgaben zu bewältigen, so dass die Entwickler nicht immer mit Anpassungen und neuen Releases belastet werden, wenn eine Änderung erforderlich ist.

Bei dieser Technik wird der Seiteneditor zum App-Editor. Marketing Teams können die Apps, die sie benötigen, in einer WYSIWYG-Umgebung erstellen und in einer Live-Vorschau mit dem Nutzererlebnis des Endbenutzers arbeiten. Die JavaScript-Frameworks unterstützen alle diese Technik – aber die Entwickler müssen darauf achten, Anwendungen so dynamisch zu erstellen, dass sie „on-the-fly“ geändert werden können. Der wesentliche Unterschied besteht darin, dass nicht mehr hart kodiert wird, welche Komponenten genau innerhalb einer übergeordneten Komponente verschachtelt sind. Stattdessen wird eine Liste möglicher Komponenten spezifiziert, die dort enthalten sein können. Wenn die App initialisiert wird, lädt sie eine JSON-Konfigurationsdatei, die definiert, welche Komponenten tatsächlich an jeder Stelle instanziiert werden.

Es gibt bereits einige schöne Bibliotheken, die das Ganze vereinfachen, wie React Habitat von Deloitte.

Fazit

In den letzten 15 Jahren schwang das Pendel zugunsten von strikter Trennung von Inhalt und Präsentation hin und her. Aber jetzt sehe ich eine schöne Möglichkeit mit dem Hybrid-Headless-Ansatz auf subtile, weniger extreme Art und Weise Aspekte aus beiden Welten zu nutzen.

Dieser Artikel erschien zuerst auf Englisch im Magnolia-Blog.

Unsere Redaktion empfiehlt:

Relevante Beiträge

X
- Gib Deinen Standort ein -
- or -