Headless CMS umgestalten

Es ist an der Zeit, Headless CMS ins rechte Licht zu rücken

Nach meinen Berechnungen ist es etwas mehr als sieben Jahre her, dass das erste absichtlich headless CMS auf den Markt kam. Man hatte schon seit Jahren Remote-APIs verwendet, aber im Januar 2013 lernte ich zum ersten Mal ein neues Unternehmen kennen, das sich später zu einem großen Anbieter von Headless CMS entwickeln sollte. Daher bezeichne ich dies als den Beginn des Branchenwandels, der heute in vollem Gange zu sein scheint.

Wenn von Headless die Rede ist, werden oft Worte wie "revolutionär" in den Mund genommen. Jeder möchte natürlich behaupten, dass er ein bisher verborgenes Geheimnis gelüftet hat, aber ist Headless nach fast einem Jahrzehnt überhaupt noch so revolutionär?

Erinnern Sie sich noch an die Zeit, als ein Blackberry die einzige Möglichkeit war, E-Mails aus der Ferne abzurufen? Das war ein einzigartiger Vorteil, den nur sie besaßen. Unweigerlich wurde dies zu etwas, das jeder tat. Die Idee, E-Mails unterwegs abzurufen, war einfach ein zu großer Vorteil, als dass man sich auf einen Anbieter beschränken konnte. Blackberry war der Pionier dieses Paradigmas, aber es konnte es nicht eindämmen.

Wir müssen uns darüber im Klaren sein, dass "kopflos" für verschiedene Menschen unterschiedliche Dinge bedeutet. Vielleicht nicht der Begriff "Headless" selbst, sondern vielmehr das, was die Menschen damit erreichen wollen und die Vorteile, die sie sich davon versprechen.

Die objektive Definition von Headless CMS ist einheitlich: Es handelt sich um ein CMS, das keine direkte Auslieferung vornimmt. Ein Headless CMS rendert keine Webseiten oder App-Schnittstellen. Das einzige, was es preisgibt, sind reine Daten in Form einer Remote-API, die JSON ausgibt. Was Sie damit machen, bleibt Ihnen überlassen.

Und was die Leute mit Headless CMS machen wollen, scheint sich deutlich verzweigt zu haben. Es gibt inzwischen zwei verschiedene Lager, denen ich meine eigenen Namen zuordne.

1. Rich Templating: Die Benutzer in diesem Lager wollen clientseitige Techniken wie React und Vue verwenden, um Schnittstellen zu erzeugen. Sie wollen insbesondere kein vom Server gerendertes, statisches HTML verwenden.
2. Kanalverteilung: Die Benutzer in diesem Lager möchten das CMS als Single-Sourcing-Tool verwenden, so dass sie ihre Inhalte in anderen Vertriebskanälen wiederverwenden können. Sie betrachten den Web-Kanal nur als einen von vielen und möchten sicherstellen, dass die Inhalte nicht web-spezifisch sind.

Diese beiden Verwendungszwecke schließen sich natürlich nicht gegenseitig aus - viele Leute wollen beides tun. Häufiger erhalten wir jedoch Anfragen von Unternehmen, die auf einen Anwendungsfall fixiert sind und den anderen vielleicht gar nicht wahrnehmen.

Ein Front-End-Entwicklungsteam arbeitet vielleicht nur an einer einzigen Website, möchte aber React verwenden und benötigt eine Remote-Datenquelle, die ihm JSON liefert. Ein Backend-Entwicklungsteam benötigt vielleicht einen Ort zum Speichern von Inhalten, die es über verschiedene APIs in mehrere Kanäle schickt. In beiden Fällen ist den Beteiligten die Verwendung des "anderen" Stils vielleicht gar nicht in den Sinn gekommen.

Die beiden Anwendungsfälle lassen sich fast durch die Akzeptanz oder Ablehnung des Webkanals selbst charakterisieren.

Wenn ein Benutzer Rich Templating verwenden möchte, lehnt er das Web Content Management nicht ab, sondern begrüßt es sogar. Dafür brauchen Sie kein ausschließliches Headless CMS. (Trotz aller Vorhersagen über den Tod von Web CMS bin ich mir ziemlich sicher, dass Sie diesen Artikel immer noch in einem Browser lesen...)

Tatsächlich sind Sie mit einem Web CMS, das über flexible Templates und eine Headless CMS-Schnittstelle verfügt, besser bedient. Es gibt eine ganze Reihe hart erarbeiteter web-spezifischer Funktionen, die ein Web CMS bietet und die nicht irrelevant sind, nur weil Sie sich entschieden haben, Ihre Site anders zu gestalten - Sie arbeiten immer noch mit einem "seitenähnlichen" Modell, und Dinge wie Navigation und Inhaltsstruktur sind immer noch wichtig.

Käufer müssen verstehen, dass die Verwendung von React kein absoluter Umsturz ist und nicht zu einer architektonischen Entscheidung werden sollte.

In kompetenten Systemen sollten die Templating-Sprachen immer austauschbar sein. Optimizely basiert auf ASP.NET MVC, bei dem das Templating von einer so genannten ViewEngine verwaltet wird. Die Standard-ViewEngine verwendet Razor, die Standard-Templating-Sprache von Microsoft.

Aber was, wenn Ihnen die Standard-ViewEngine nicht gefällt? Nun, dann tauschen Sie sie einfach gegen Ihre eigene aus. Nur sehr wenige Menschen tun dies, aber die Option wird vollständig unterstützt.

Nur zum Spaß habe ich es ausprobiert. In 17 Minuten - einschließlich der Recherchezeit - hatte ich eine neue ViewEngine "geschrieben" und in einer Optimizely Site installiert, die den Titel des Inhaltsobjekts im Klartext wiedergab. (Ich habe "geschrieben" in Anführungszeichen gesetzt, weil ich glaube, dass sie nur sechs Zeilen Nicht-Boilerplate-Code enthielt). Es war völlig nutzlos, aber es hat gezeigt, dass die Templates von Optimizely locker gebunden und leicht austauschbar sind.

(Ich will nichts versprechen, aber ich habe ein internes Proof-of-Concept gesehen, bei dem eine Site von Optimizely mit Fluid erstellt wurde. Das bedeutet, dass ein Optimizely-Projekt von einem Frontend-Ingenieur erstellt werden könnte, ohne dass er Visual Studio jemals anfassen muss. Bleiben Sie dran.)

Aber so einfach, wie der Wechsel des Templating-Systems ist, ist er auch nicht mehr notwendig - vor zwei Monaten haben wir unsere Foundation SPA React Site veröffentlicht, die eine Optimizely Site mit React als Template verwendet. Um die Leistung zu verbessern, wird die erste Anfrage mit serverseitigem React gerendert. Diese wird im Browser in eine vollständige, aktive React App umgewandelt. (Das ist kein einzigartiges Modell - progressive Web-App-Generatoren wie GatsbyJS tun dasselbe).

Der springende Punkt ist folgender: Rich Templating wird schnell zur Norm. Es ist nicht mehr nötig, ein Headless CMS zu suchen und auf eine ganze Reihe von Funktionen zu verzichten, nur weil Sie React verwenden möchten. Während Optimizely traditionell serverseitiges Templating verwendet hat, erreichen wir schnell eine Parität zwischen diesem und clientseitigem Templating. Wir bereiten uns auf einen Tag vor, an dem niemand mehr HTML serverseitig rendert.

Um es ganz klar zu sagen: Es ist meine persönliche Mission, die Auswirkungen Ihrer Templating-Entscheidung auf eine Stilentscheidung zu reduzieren. Sie sollten das nicht an eine Architekturentscheidung binden müssen.

Lassen Sie mich sogar eine Herausforderung an alle anderen CMS-Anbieter aussprechen: Gehen Sie davon aus, dass das gesamte Templating innerhalb der nächsten 18 Monate auf die Client-Seite verlagert wird. Überprüfen Sie Ihre Systeme rücksichtslos, um sicherzustellen, dass alle Ihre Auslieferungsfunktionen sowohl mit der serverseitigen als auch mit der clientseitigen Auslieferung funktionieren, und fügen Sie keine neuen Funktionen hinzu, die nicht in beide Richtungen funktionieren. Wir müssen gemeinsam mit dem Eindruck aufräumen, dass "reines" Headless die einzige Möglichkeit ist, dies zu tun.

Auf der anderen Seite versuchen Unternehmen, die einen Vertriebskanal suchen, sich vom Webkanal abzukoppeln. Sie lehnen ihn vielleicht nicht ganz ab, aber sie haben andere Kanäle, in denen sie ihre Inhalte nutzen wollen, und sie wollen Flexibilität gewährleisten.

Optimizely hat schon immer das .NET-Framework genutzt und somit von allen Funktionen und Werkzeugen profitiert, die damit einhergingen. Weiterentwicklungen wie MVC und WebAPI waren automatisch auf eine Optimizely Site anwendbar.

Vor einem Jahrzehnt war ich an Headless-Projekten mit Optimizely beteiligt. Damals verfügte das Produkt noch nicht über eine spezielle headless API, aber das war auch nicht nötig, denn das .NET-Framework bot so viele erweiterte Funktionen, dass man einfach nur ein paar Teile zusammenkleben musste, um es headless zu machen.

Heute hat unsere Content-Bereitstellungs-API dies in einem einzigen Framework vereint. Sie können über spezielle URL-Endpunkte auf Inhalte zugreifen und den Inhaltsbaum durchqueren (oder einfach die normale URL einer beliebigen Seite mit einem bestimmten Accept-Header aufrufen). Mit Optimizely Search & Navigation haben Sie erweiterten Zugriff auf gezielte, parametrische Abfragen von Inhalten, die auf einer beliebigen Kombination von Daten basieren.

Und es sind nicht nur Seiten. Optimizely unterstützt ungebundene Inhaltselemente, die nicht an eine URL gebunden sind. Es handelt sich einfach um strukturierte Inhaltsdatensätze, die in andere Inhalte integriert werden können. Sie können auf die Seitenoberfläche gezogen werden, um gerendert zu werden, oder sie können nur als Daten ohne visuelle Anzeigekomponente existieren.

Zu Beginn dieses Jahres haben wir den Content Manager veröffentlicht, eine alternative Benutzeroberfläche für die Bearbeitung von Inhalten. Er bietet keine Funktionen für die Verwaltung des Webkanals, sondern lediglich eine optimierte Oberfläche für das Auffinden und Bearbeiten von Inhaltsdatensätzen jeglicher Art. Redakteure, die den Content Manager verwenden, müssen keine größeren Konzepte der Website-Verwaltung verstehen - sie können mit Inhalten arbeiten, ohne sich um den Lieferkanal zu kümmern.

Mit Content Manager verfügen Sie über ein Headless CMS, das innerhalb eines CMS mit vollem Funktionsumfang läuft. Sie haben vielleicht einige Redakteure, die nur Inhalte verwalten, nicht aber den Webkanal. Ihre Website wird zu einem Wrapper mit zusätzlichen Funktionen um Ihre Inhalte herum. Das ist ein Unterschied, und Sie haben jetzt Tools für beides.

Lassen Sie mich mit einem wichtigen Punkt abschließen

Bis jetzt habe ich über die neuen Funktionen gesprochen, die Optimizely zu einer guten Wahl für Headless-Projekte machen. Was ich noch nicht erwähnt habe, ist viel wichtiger: All diese Funktionen wurden auf einer der stärksten Content-Management-Plattformen der Branche aufgebaut.

Optimizely hat nicht bei Null angefangen. Wir haben mit einer kompletten, kampferprobten Grundlage für die Verwaltung von Inhalten begonnen und haben einfach ein Headless Tooling darauf aufgebaut. Wir müssen nicht zurückgehen und die grundlegenden Probleme von CMS lösen. Wir haben lediglich ein neues Paradigma der Bereitstellung eingeführt.

In meinem ersten Buch (und in meinem anschließenden College-Kurs) habe ich die so genannten vier Säulen des Content Management hervorgehoben. Sie sind:

1. Inhaltsmodellierung: wie Sie Ihre Inhalte beschreiben
2. Aggregation von Inhalten: wie Sie Ihre Inhalte organisieren, um einen größeren Nutzen zu erzielen
3. Redaktioneller Workflow und Tools: wie Sie den Prozess der Erstellung und Bearbeitung von Inhalten verwalten
4. Publikations- und Delivery Management: wie Sie Output-Artefakte auf der Grundlage Ihrer Inhalte erzeugen

Jahrelang waren diese vier Dinge der absolute Kern eines CMS. Sie waren hersteller- und architekturübergreifend.

Was geschah, als Headless CMS aufkam? Wurde damit das gesamte Modell umgestoßen?

Nein. Es änderte nur den letzten Punkt - das Veröffentlichungs- und Bereitstellungsmanagement. Alles, was die Anbieter von Headless CMS taten, war, dies auf andere Tools zu verlagern. Die Modellierung, Aggregation und die redaktionellen Werkzeuge ändern sich nicht, nur weil Sie sich für React entscheiden.

(Deshalb ärgere ich mich über Behauptungen, Headless CMS sei "weniger komplex" als herkömmliche CMS. Es ist nicht weniger komplex, sie haben nur einen Teil der Komplexität ignoriert. Sie müssen sich immer noch um die Auslieferung kümmern, es ist jetzt nur Ihr Problem, nicht das der anderen. Das ist so, als würde ein Autohersteller seine Produkte "zuverlässiger" machen, indem er sie ohne Motor verkauft).

Optimizely war schon immer ein großartiges CMS. Das wusste ich von dem Moment an, als ich 2008 meine erste Demo sah, und das hat sich in 11 Jahren professioneller Dienstleistungen und jetzt seit fast einem Jahr als Senior Director of Content Management Strategy nicht geändert.

Ich möchte keineswegs herunterspielen, wie sehr Headless diese Branche verändert hat, aber die Paradigmenwechsel, die Headless bewirkt hat, sind nicht mehr "revolutionär". Und die Architektur von Optimizely ist so beschaffen, dass es für uns ein Leichtes war, uns strategisch neu auszurichten.

Wenn Sie das gesamte Spektrum dessen betrachten, was Unternehmen mit Inhalten tun müssen - von der Ideenfindung über die Verwaltung bis hin zur Bereitstellung und Optimierung -, tritt die Wahl der Bereitstellungsarchitektur und des Kopplungsmodells ein wenig in den Hintergrund. Sie ist zwar wichtig, sollte aber nie der alleinige Grund für die Produktauswahl sein.

Bringen Sie Ihr JavaScript-Framework und alle Ihre Nicht-Web-Kanäle mit. Wir werden sie mit unserer gesamten Suite von Content-Management- und Optimierungs-Tools abgleichen. Wir versprechen Ihnen, dass Ihnen das Ergebnis gefallen wird.

Optimizely passt sich schnell an eine API-first Welt an, und wir bringen 25 Jahre Erfahrung im Bereich Content Management mit.