Headless, Jamstack, ReactJS 

Das Web hat sich in den letzten 15 Jahren radikal geändert. Die Technologie hinter Websites, die CMSe, dagegen leider nicht. Wie bereits in Teil 1 und Teil 2 erläutert, behindern komplexe Architekturen und veraltete Technologien die intuitive und schnelle Website-Entwicklung. Redakteure werden immer noch damit belastet, umfangreiche Formulare ausfüllen und auf Vorschau-Buttons klicken zu müssen. CMSe sind bekannt für schreckliche Usability, veraltete Technologien, hohe Betriebskosten und ständige Sicherheitslücken. Kommerzielle Angebote sind nur teurer, aber nicht besser. Im Folgenden lernen Sie alles über neue Ansätze wie Headless CMS und JAMstack und neue Technologien wie ReactJS

Frontend

Die moderne JAMstack-Webarchitektur – JavaScript, APIs, Markup – funktioniert zusammengefasst folgendermaßen: Wenn der Nutzer eine Seite anfragt, wird ihm von einem globalen CDN vorausberechnetes HTML-Markup und JavaScript ausgeliefert. Unsere zwei Hauptprobleme, Skalierbarkeit und Sicherheit, sind damit gelöst. Da die Site global auf vielen Servern gespeichert ist, funktioniert sie auch dann und wird schnell geladen, wenn sie von sehr vielen Besuchern gleichzeitig abgerufen wird. Für die Sicherheit ist entscheidend, dass die Seiten nicht mehr serverseitig generiert werden, sondern von einer im Browser laufenden JavaScript-Webanwendung, an den nur statische Dateien ausgeliefert werden müssen – das ist durch moderne Cloud-Computing-Provider äußerst sicher machbar. Die gute Performance kommt durch den Einsatz eines CDN zustande und dadurch, dass nun kein Server mehr die Seiten auszurechnen braucht, sondern der Browser des Besuchers diese Rechenleistung erbringt.

Der Betrieb einer solchen Website beschränkt sich damit darauf, Dateien zu hosten oder hosten zu lassen. Davon entkoppelt ist die Entwicklung der Webanwendung. Beim „Decoupling” wird die Website als JavaScript-Anwendung lokal entwickelt und dann beim Deployment als statisches HTML und JavaScript-Dateien auf den Servern abgelegt.

JavaScript wurde zur browserseitigen Ausführung dynamischer Webanwendungen konzipiert. Die klassische, auf einem Server laufende Website wird also durch eine Anwendung im Browser ersetzt, was nicht nur die Sicherheit erhöht, sondern ein ganz neues Level an Dynamisierung und Personalisierung ermöglicht, da das Aussehen und die Inhalte ja erst auf dem eigentlichen Endgerät bestimmt werden.

Die Performance lässt sich durch den Einsatz modernster Frameworks wie ReactJS noch weiter erhöhen. Berechnet man alle Seiten beim Deployment als statisches HTML vor („Pre-Rendering”) und „reanimiert” das statische Markup nach dem Laden wieder durch ReactJS, bleiben serverseitig nichts weiter als statische, HTML-Dateien, CSS-Dateien und JavaScript-Dateien übrig. Die im Browser laufende JavaScript-Anwendung kann nun wiederum aus beliebigen externen Quellen via APIs (ERPs, CRMs, Kundendatenbanken, etc.) Daten konsumieren und beim Anzeigen der Seite verwenden. Dies ermöglicht es, alle Vorteile statischer Websites mit hyperdynamischen Sites zu kombinieren. Insbesondere das schnelle Präsentieren der Seite durch Pre-Rendering wirkt sich positiv auf den Google-Score aus, bei dem die Ladezeit einer Seite immer mehr zu einem der wichtigsten Faktoren wird.

Diese Technologie lässt den Browser zur eigentlichen Integrationsplattform für die Vielzahl der Dienste werden, die heute digital angeboten werden. JavaScript-Webanwendungen bilden das Frontend für Content-Management, CRM-, ERP-, E-Commerce- und zahllose andere, auch verbundene Lösungen. In Verbindung mit „Serverless Computing” lassen sich hochmoderne Anwendungen entwickeln, ohne sich jemals um Datensicherheit, Stabilität, Performance usw. Gedanken machen zu müssen. Wie stellt man aber nun in diesem JAMstack-Kontext am geschicktesten Backend-Funktionalität via APIs für den Browser bereit?

Backend

Das klassische Backend in einer On-premise-Infrastruktur mit Datenbanken, User-Management, Monitoring etc. und dem damit verbundenen Administrationsaufwand hat heute nur noch in Ausnahmefällen seine Berechtigung. Die neue Architektur heißt Serverless Computing. Amazon hat als erster Anbieter am Markt einen „Event-Driven Compute Service”, AWS Lambda, vorgestellt. Andere haben nachgezogen, etwa Microsoft mit „Azure Functions” oder Google mit „Cloud Functions”.

Diese neuen Services bieten eine ganze Reihe von Möglichkeiten, um Schnittstellen zu Backend-Diensten zu entwickeln, auf die aus verschiedenen Gründen nicht direkt aus der Frontend-Webapplikation heraus zugegriffen werden kann (z.B. Authentifizierungssysteme). Auch ein ganzes Backend-as-a-Service wie z.B. ein CRM-System ließe sich damit in der Cloud betreiben.

Beim Serverless Computing geht es überwiegend um den Business Value, also den zu schaffenden Nutzen. Hierfür muss kein einziger Server administriert werden. Stattdessen sorgt der Serviceanbieter dafür, dass stets genügend Ressourcen für die Ausführung der jeweiligen Serverless-Funktionen zur Verfügung stehen.

Ein weiterer Vorteil des „Serverless Computing” ist, dass Funktionen basierend auf deren Nutzung abgerechnet werden. Wenn niemand klickt, entstehen auch keine Kosten (pay-per-use). Darüber hinaus braucht man sich nicht um Skalierung, Provisionierung, Patching oder Updates zu kümmern. Insgesamt werden Backend-Funktionen und -Applikationen durch „Serverless Computing” kostengünstiger, belastbarer sowie sicher und wartungsfrei. Ferner werden die Funktionen typischerweise auch mit JavaScript erstellt, also mit derselben Programmiersprache, mit der man auch am Frontend nach dem JAMstack-Prinzip seine Website baut. Folglich benötigt man nur eine einzige Technologie, auf der man seine gesamte Web-Entwicklung aufbauen kann, was viel effizienter und einfacher ist, als die Webentwicklung an die Technologien anzupassen. Im Endeffekt dienen JAMstack und „Serverless Computing” dazu, die Komplexität auszulagern. Sie ist zwar immer noch vorhanden, doch kümmern sich nun andere darum, die Anbieter.

CMS

Um die Anforderungen an API-fähige CMSe zu erfüllen, sind in letzter Zeit sogenannte Headless CMSe in Mode gekommen, die allen Content über APIs zur Verfügung stellen, die dann wieder beispielsweise vom JavaScript konsumiert werden können. Headless CMS + JAMstack + Serverless Computing = DIE perfekte Lösung? Nicht ganz. Es gibt noch einige Punkte, bei denen ein reines Headless CMS Anforderungen an eine moderne CMS-Lösung in keiner Art und Weise erfüllt:

Das Web ist ein visuelles Medium. In einem einfachen reinen Headless-CMS-Ansatz haben wir jedoch nur eine etwas bessere Remote-Datenbank. Was hier folglich nicht angeboten wird, sind eine einfache und intuitive Bedienoberfläche, eine komponentenbasierte Architektur, eine Seitenvorschau, kollaborative Bearbeitung in Echtzeit, ein URL- und Hierarchie-Management, anpassbare Berechtigungen, eine Volltextsuche und vieles mehr. Diese Systeme sind häufig nur von technisch versiertem Personal zu bedienen und erfüllen damit die Anforderungen an moderne CMSe nicht.

Ein herkömmliches marktübliches Headless CMS reicht demzufolge nicht aus, ein herkömmliches System der alten Bauart jedoch auch nicht.

Grob kann man alle existierenden Headless Content-Management-Systeme in 4 Kategorien einteilen:

1. Open Source Systeme: Diese Systeme sind weit verbreitet und leben in einem großen Ökosystem. Allerdings ist deren Benutzeroberfläche in keiner Weise benutzerfreundlich, und sie basieren alle auf veralteten Technologien wie PHP und Java. Zudem sind sie serverbasiert, sodass man wieder installieren, patchen und verwalten muss, was zu einer häufig unterschätzten und sehr hohen Total-cost-of-Ownership führt.

2. Kommerziell: Die kommerziellen Systeme unterscheiden sich nur wenig von den Open-Source-Systemen. Manche sind zwar deutlich benutzerfreundlicher als Open-Source-Software, generell aber sind sie technisch genauso veraltet, keine Native-Cloud-Systeme und haben dafür meist sehr hohe sechs- bis siebenstellige Lizenzgebühren.

3. Cloud-Website-Baukästen: Diese „Website-Builder” glänzen indes mit einer intuitiven und einfachen Benutzeroberfläche. Dennoch fehlen Funktionen, Schnittstellen und Anpassungsmöglichkeiten. Mit ihnen kann man nicht einfach die Website eines mittelständischen Unternehmens bauen, geschweige denn von weltweiten Organisationen.

4. Pure-Headless-CMS: Diesen Systeme laufen zwar in der Cloud, sind multi-tenancy-fähig und haben ein API, aber es fehlt das komplette User-Interface mit In-Place-Editing, modularen Seitenkomponenten, etc.

Was steht also auf unserer Wunschliste für ein modernes JAMstack-CMS?

• - WYSIWYG-Editing
• - Modulare, komponenten-basierte Seitenstrukturen
• - Drag-and-Drop-Funktion
• - Auto-Saving
• - Paralleles Bearbeiten
• - SEO-Funktionen
• - Social-Media-Funktionen
• - Media-Asset-Management
• - Hierarchien und Navigationen
• - Anpassbare Berechtigungen
• - Serverless
• - Cloud-basiert
• 
  

Die Kombination aus diesen leistungsfähigen Funktionen wird man bei einem reinen Headless CMS nicht finden. Bei einem Headless CMS „with a head” jedoch schon, denn hier werden eben diese Anforderungen entsprechend berücksichtigt. Mit unserem Content-Management-System Scrivito haben Sie die Möglichkeit, die neuen Ansätze JAMstack und Serverless zu nutzen. Mit Scrivito können Sie eine Website erstellen, die nicht nur sicher, skalierend und hochverfügbar ist und serverless funktioniert, sondern darüber hinaus Redakteuren ein Lächeln ins Gesicht zaubern wird.

Überzeugen Sie sich selbst und testen Sie unser CMS Scrivito jetzt einen Monat lang kostenlos.

Unsere Lese-Empfehlungen

👉 „Decoupled“ und „Headless“ CMS im Überblick

👉 Headless und Decoupled CMS erklärt