API statt Apache: Warum Headless CMS das Content-Business umkrempelt

Apps, Tablets, Messenger, Connected-Cars, Smartwatches und immer mehr Internet-der-Dinge: Keine Frage, im Internet haben sich die Nutzungsgewohnheiten in den vergangenen Jahren drastisch gewandelt. Wie tiefgreifend diese Änderung ist, zeigt ein Blick gerade einmal fünf Jahre zurück: 2011 ist in Deutschland das Facebook  -Fieber gerade ausgebrochen, jede Sekunde melden sich sieben neue Nutzer an, der Börsengang steht kurz bevor. Apple   hat eben erst das iPad vorgestellt, der App-Store ist noch keine drei Jahre alt und verfügt über gerade 350.000 Programme. Das aktuelle Smartphone heißt iPhone 4, Siri   ist der Welt noch nicht bekannt. Dafür sind Messenger schon längst erfunden: Die populärsten heißen Skype   und CuSeeMe  .

Das Wichtigste jedoch: Vor fünf Jahren dominierten Webbrowser und Mail-Client beinahe unangefochten als universelle Zugangsmöglichkeiten zum Internet. "Internet" war quasi gleichbedeutend mit "Web".

Im Jahr 2016 sieht die Welt ganz anders aus. Webbrowser und Mail-Client sind fraglos weiterhin von Bedeutung. Doch ihre Gatekeeper-Funktion haben sie eingebüßt: Facebook ist für viele Nutzer zum neuen Einstiegspunkt geworden - natürlich nicht per Browser, sondern als App. Suchanfragen werden per Sprachassistent an die Server übertragen. Jede Sekunde rasen weltweit rund 350.000 Nachrichten allein durch's WhatsApp  -Netzwerk. Smart-TVs haben die Wohnzimmer erobert. Produkte und Bilder werden in Apps von Amazon und Instagram   gesucht. Zeitungen und Zeitschriften publizieren nicht nur auf ihren Onlinekanälen, sondern ebenso in Social Media, auf dem Smartphone oder bei Aggregatoren wie Blendle   oder Readly  . Und immer mehr Services werden mit Schnittstellen zu Bezahldiensten (Paywall) oder Single-Sign-In-Diensten ausgestattet.

Schon an dieser Auflistung zeigt sich, dass sich in äußerst kurzer Zeit die Anforderungen ans Web-Publishing rapide gewandelt haben. Und: Nichts deutet darauf hin, dass sich an dieser Entwicklung in Zukunft etwas ändern würde. Im Gegenteil: Messenger werden gerade als nächstes großes Ding gehypt. Smarte Bots sollen dort - von der Fahrplanauskunft über die Newsrecherche bis zum Geldtransfer - viele Aufgaben erledigen, wegen denen wir bislang den Browser bemühen. Connected-Cars und Smartwatches werden ihre Bedeutung als Einfallstore ins Internet ausbauen und immer mehr Alltagsgeräte - von der Küchenmaschine bis zur Heizungssteuerung - werden vernetzt.

Es liegt auf der Hand, dass immer mehr Internetkommunikation in den kommenden Jahren nicht mehr von einem Webbrowser initiiert wird und keinen Webserver wie Apache   zur Beantwortung erfordert. Die Vormachtstellung des Browsers ist gebrochen. Er ist nur noch eine Zugangsmöglichkeit unter vielen. Zugleich steigen die Ansprüche an die Vernetzung: Content-Aggregatoren fordern präzisen Zugang zu (Teil-)Informationen, verschiedene Endgeräte und Angebote werden über Kreuz verbunden und müssen sich gegenseitig autorisieren.

Natürlich ist eine solche grundlegende Neustrukturierung nicht möglich, ohne dass sich auch die Ansprüche an Content-Management-Systeme tiefgreifend ändern würden. "Der Bedarf an Multichannel-Kommunikation und zentralen Redaktionsprozessen führt zu deutlich strukturierteren Datenzugriffen", hat etwa Michael Märtin , Geschäftsführer der Atlantis Media    erkannt. "Nicht nur Websites, sondern auch Landingpages, Online-Magazine und Apps müssen mit Inhalten versorgt werden." Sprich: Die Informationsbereitstellung muss kleinteilig erfolgen und eine Vielzahl von Anwendungsszenarien unterstützen. Mehr noch: Idealerweise ist die Informationsbereitstellung gänzlich unabhängig von der Applikation (siehe iBusiness: Content-Marketing - Diesen Anforderungen muss Ihr CMS in Zukunft genügen).

Die Antwort ist: Headless

Schon die Klassifizierung herkömmlicher Content-Management-Systeme (CMS) lässt erahnen, wo die Lücke klafft: Zwischen Enterprise- und Web-CMS. Für die Bereitstellung von Wetterinformationen (z.B. für die Smart-Home-Steuerzentrale) oder Songtexten (z.B. für die Musik-Streaming-App) ist weder das eine noch das andere System geeignet. Erstere scheiden schon auf den ersten Blick aus, weil sie komplett unhandlich und überdimensioniert sind. Da scheinen die kleineren Web-CMS schon deutlich besser. Doch auch sie weisen einige entscheidende Einschränkungen auf:

Die Stärke von regulären Content-Management-Systemen liegt darin, dass auf der einen Seite Inhalte hineingeschaufelt, systematisiert, organisiert und verwaltet werden und mit wenig Aufwand auf der anderen Seite eine individualisierte und personalisierte Website ausgeworfen wird - zumindest wenn der Website-Manager dazwischen seine Arbeit richtig gemacht hat. Selbst viele Website-Funktionalitäten (sei es Login, Kommentarfunktion oder Transaktionen) werden vom CMS bereitgestellt.

Dies bedeutet aber auch, dass die gespeicherten Daten mit einer ganzen Reihe vordefinierter Funktionen ausgeliefert werden. Neben dem Content-Repository (in dem die Inhalte verwaltet werden) ist die Template-Engine elementarer Bestandteil des CMS. Dort werden die Anfragen bearbeitet sowie Inhalt, Layout und Funktionalität zu einer fertigen Website gemischt. Das bedeutet:

• Der Content wird immer mit Template-Informationen aufbereitet.
  
• Ein Webserver gibt die formatierten Inhalte aus.
  
• Die Inhalte werden immer beim Webserver (durch einen View) angefordert.

Dieser Ablauf ist in den oben geschilderten Anwendungsfällen oft komplett hinderlich. Beispiel Wetterbericht in der Steuerzentrale des Smart Homes: Würde die Vorhersage von einem Web-CMS bereitgestellt, müssten die Daten einerseits geparst und neu aufbereitet werden, damit die reine Information bereitsteht. Drückt der Anwender den "Mehr"-Button, der neben dem Wetterbericht des Tages angezeigt wird, müsste außerdem ein neuer View ausgelöst werden, damit die Wettervorhersagen für die weiteren Tage geladen werden.

Ein Headless CMS ist dagegen weder auf einen View angewiesen, noch liefert es Template-Informationen mit. Es besteht ausschließlich aus dem Backend für Redakteure und Mitarbeiter, der eigentlichen Datenbank (Repository) sowie der Logik zur Verwaltung. Es fehlt: Das Frontend. Stattdessen gibt es eine API (meist RESTful), auf die die verschiedenen Applikationen zugreifen können. Beim Headless CMS greift das Frontend der Heizungssteuerung also direkt auf den Datensatz mit den Wetterinformationen zu. Das CMS liefert diese Daten personalisiert (Datum, Region) aus und die App verarbeitet sie mit anderen Daten (etwa Raum- und Kesseltemperatur) und weiteren beliebigen Informationen zur kompletten Frontend-Ansicht. Werden neue Inhalte benötigt (Stichwort: "Mehr"-Button), werden diese dynamisch nachgeladen. Es ist nicht nötig, einen neuen View abzurufen.



Ob es am Ende mehrere Applikationen, Webseiten oder andere Medien gibt, welche sich aus den Inhalten des Headless CMS bedienen, ist egal. Es muss nur noch eine Quelle bearbeitet werden, um mehrere Produkte gleichzeitig zu speisen. Vorteile:

• Daten und Inhalte werden über eine standardisierte API ausgeliefert.
  
• Die API lässt sich mit den unterschiedlichsten Programmiersprachen aus den verschiedensten Anwendungen ansprechen.
  
• Inhalte können serverübergreifend abgerufen und an anderer Stelle punktuell eingesetzt werden.

Ein weiterer Vorteil eines Headless CMS sind die dynamischen Abfragen der RESTful-API. Dadurch ist es möglich, auch nach dem Aufruf der Webseite Daten abzufragen und dynamisch einzubetten. Dieses Prinzip lässt sich zwar auch in einem Browser unter Verwendung von JavaScript erzielen. Allerdings müssen dann die kompletten Inhalte bereits beim ersten View übertragen werden. Das JavaScript speichert sie und zeigt sie erst bei Bedarf an. Werden zu wenige Informationen übertragen, ist ein erneuter Pageview erforderlich. Werden zu viele übertragen, leidet die Performance. Anders beim Headless CMS: Die Abfrage über RESTful-APIs ist jederzeit dynamisch möglich. Das Frontend kann den Content komplett flexibel anfordern und verarbeiten.

Die Rückseite der Medaille

So modern und zukunftsweisend Headless CMS auf der einen Seite sind, so fordern sie auf der anderen Seite auch einigen Tribut. Insbesondere ist in den vergangenen Jahren viel Knowhow in Frontend-Features geflossen. Dies können einerseits komplette Komponenten wie eine ECommerce-Funktionalität sein, die das CMS mit abdeckt. Wird das CMS-Frontend deaktiviert, müssen diese Funktionen selbst nachprogrammiert werden. Aber auch unter der Haube steckt meist viel Entwicklungsarbeit. In klugen Caching-Konzepten, optimiertem Seitenaufbau und smarten JavaSripts für's Rendering steckt bereits viel Gehirnschmalz. Wird das eingebaute Front-End aufgegeben, bedeutet dies für die Web-Performance nicht unbedingt Gutes. Außerdem muss viel Zeit, Geld und Mühe in den Nachbau bereits gut funktionierender Features gesteckt werden.

Hinzu kommt, dass auch REST (Representational State Transfer) nicht der Weisheit letzter Schluss ist. Gerade wenn eine Abfrage Inhalte aus mehreren Quellen benötigt, werden viele Ressourcen verbraucht. Um dieses Performance-Problem zu bändigen, können zwar individuelle API-Endpunkte definiert werden - doch auch dies kann zu Problemen führen. Allein die Verwaltung vieler Endpunkte kann zu einer Mammutaufgabe werden. Steht eine Aktualisierung an, muss zudem der gesamte Code angepasst werden, der die Daten des individuellen Endpunkts entgegennimmt. Dies bedeutet aber, dass alle Vorarbeiten im Backend abgeschlossen sein müssen, bevor das Frontend aktualisiert wird. In der Entwicklung entsteht ein Flaschenhals.

Auch die Anforderungen an das Hosting ändern sich. Anfragen kommen nicht mehr nur von einer Webseite, sondern von mehreren Applikationen und Medien, die alle (mittelbar) auf die Datenbank zurückgreifen wollen. Der Server des Headless CMS muss dieser Aufgabe gewachsen sein und die Anfragen innerhalb kürzester Zeit abarbeiten. Bei einem Serverausfall sind die damit verbundenen Applikationen oft viel direkter betroffen, da sie oftmals gar nicht mehr arbeiten, wo zuvor nur eine Teilinformation ausgefallen ist.

Königsweg "Schrittweise Entkopplung"

So verlockend auf der einen Seite die Vorteile einer Entkopplung von Frontend und CMS sind, so nachvollziehbar sind andererseits die Einwände. In der Praxis hat ein Unternehmen wenig davon, ein bestehendes System einzureißen, um ein neues, enorm solides Fundament zu errichten - auf dem dann aber eine Bretterbude entsteht, weil Zeit, Geld und Kapazitäten für einen Neubau fehlen. Dann lieber im Altbau noch zwei, drei Jahre länger ein-, aus- und umbauen, bis das alte Fundament richtig ächzt ... .

Um diesen Konflikt zu entschärfen, bietet sich eine schrittweise Entkopplung ("Progressive Decoupling") an. Die Idee dahinter ist es, das bestehende CMS in seiner Gänze beizubehalten, aber Teile oder Module parallel über eine API-Erweiterung anzubieten. Auf diese Weise kann das bewährte (Web-)Frontend bestehen bleiben, während andere Applikationen und Plattformen bereits aus der API mit Inhalten versorgt werden. So können einzelne Module oder Bereiche außerhalb der Webseite zugänglich gemacht werden und trotzdem der komplette Funktionsumfang auf der Website beibehalten werden - mit allen Vorteilen der Auslieferung kompletter Pages aus der Template-Engine. Progressive Decoupling ebnet so den Weg in die neue CMS-Architektur ohne einen plötzlichen Bruch zu fordern. Entsprechende API-Erweiterungen sind für viele Content-Management-Systeme erhältlich.

Digitalisierung statt World Wide Web

Insgesamt ist ein Headless CMS keine Investition ins Web, sondern in die Digitalisierung des Unternehmens. Rein für einen Web-Auftritt sind die Vorteile kaum spürbar. Deswegen sollten Sie bei der Planung auch über aktuelle Webprojekte hinaus denken und die gesamten digitalen Kanäle Ihres Unternehmens bewerten. Ist es profitabel, die digitalen Lösungen so umzubauen, dass sie alle digitalen Kanäle bedienen können? Welche Architektur kann auf lange Sicht das digitale Geschäft am besten unterstützen und aufrechterhalten? Es sind eindeutig eher langfristige, strategische Ziele, die durch die Einführung eines Headless CMS erreicht werden. Damit dabei aber kurzfristige Lösungen nicht aus dem Fokus geraten, bietet sich in vielen Fällen die schrittweise Einführung als Königsweg an.