Headless Drupal - Was, Wann, Wie & Wo - Der ultimative Leitfaden für entkoppeltes Drupal

Auf einer herkömmlichen Drupal-Website ist Drupal die End-to-End-Lösung, um den Nutzern Seiten bereitzustellen. Es wird verwendet, um Inhalte zu erstellen, zu speichern und dem Endbenutzer anzuzeigen. Bei einem Headless-Ansatz werden hinzufügen und speichern weiterhin in Drupal durchgeführt, aber die Anzeige nicht.

Definition:

Headless Drupal ist ein Ansatz zum Erstellen von Drupal-Websites, bei dem Drupal als Backend-Inhaltsablage dient. Das Frontend wird in verschiedenen Technologien aufgebaut und kommuniziert über eine API mit Drupal. 

Im Diagramm sehen wir, dass Drupal als Backend-System dient. Das Frontend, das der Kunde sieht, ist von Drupal getrennt. Daher stammt der Name headless – Drupal hat die obere Schicht nicht mehr (den Kopf ;)), sondern stellt nur die APIs bereit, die das Frontend konsumiert und als Inhaltsquelle verwendet.

Das Frontend kann in verschiedenen Frameworks und Programmiersprachen erstellt werden. Meistens wird es jedoch einer der folgenden sein:

• Javascript – in der überwiegenden Mehrheit der Fälle werden Frontends meist auf Frameworks wie React, Angular oder Vue aufgebaut, die eine schnelle Erstellung dynamischer und interaktiver Schnittstellen ermöglichen. Wenn es erforderlich ist (z. B. für SEO-Zwecke), die Seiten auf dem Server vorzurendern, können Nextjs oder Gatsby helfen.
• PHP – manchmal wird das Frontend auf einem schnellen PHP-Framework wie Symfony oder Laravel aufgebaut. Dies wird hauptsächlich vorgenommen, wenn eine Server-Priorenderung erforderlich ist. Ein zusätzlicher Vorteil ist, dass, da Drupal auf PHP aufgebaut ist und Symfony verwendet, oft dasselbe Team in der Lage ist, das Frontend zu bearbeiten.
• Jede andere – eine Website in einer beliebigen anderen Technologie, die mit einer API kommunizieren kann, kann Inhalte von Drupal konsumieren. 

Warum Headless Drupal wählen

Es gibt viele Gründe, warum Unternehmen sich für einen Headless-Ansatz in Drupal entscheiden könnten. Im Folgenden werde ich die häufigsten nennen.

Mehr Content-Konsumenten

Heutzutage kommunizieren Marken mit ihren Kunden nicht nur über ihre Websites, sondern über mehrere Kanäle. Ein CMS wird daher nicht nur genutzt, um Inhalte an Webbrowser zu senden. Es übermittelt Inhalte an verschiedene andere Orte. Mehr über die sich verändernde Marketinglandschaft können Sie in einem Beitrag über Digital Experience Platforms lesen.

Drupal ist fantastisch positioniert, um die Quelle von Inhalten für verschiedene Konsumenten zu sein. Abgesehen davon, dass es Inhalte für eine Frontend-Website bereitstellt, kann ein entkoppeltes Drupal Inhalte über eine API bereitstellen, die von verschiedenen anderen Medien konsumiert werden, in denen die Marke präsent sein möchte:

• mobile Anwendungen
• IoT
• Kiosk-Displays
• usw.

Microsite-Manager

Manchmal benötigt ein Unternehmen mehrere separate Websites (z. B. eine für jede Marke, jedes Ereignis, jede Aktion, jedes Land), die jedoch viele Inhalte teilen. In einem solchen Fall könnte es einfacher sein, eine einzige Inhalts-Engine (Drupal) zu erstellen, die Inhalte an alle Microsites liefert. Die Microsites können schnell erstellt und geschlossen werden, wann immer Bedarf besteht und die Inhalte können in einem zentralen Hub verwaltet werden.

Bedarf an einer eleganten Benutzeroberfläche

Drupal ist großartig zur Inhaltserstellung, Datenspeicherung usw., aber es ist in PHP geschrieben, was eine serverseitige Rendering-Engine ist. Wenn ein bestimmtes Website- oder App-Design eine sehr aufwendige Benutzeroberfläche erfordert oder interaktiv ist, muss es wahrscheinlich in Javascript erstellt werden.

Javascript ermöglicht fantastische Interaktionen, die für Besucher benutzerfreundlich und schnell sind. Bibliotheken wie Angular, React oder Vue helfen Entwicklern, schnell anspruchsvolle Frontendanwendungen zu erstellen. Progressive Web Applications - ein von Google veröffentlichtes Standardkonzept, gewinnt ebenfalls an Bedeutung und erfordert, dass eine Anwendung in Javascript erstellt wird.

Wenn Sie eine interaktive Webanwendung erstellen möchten, ist die Kombination von Drupal mit einem Frontend-Javascript-Framework eine wirklich großartige Option. Für ein Tutorial können Sie unseren Artikel über die Kombination von Drupal und React anschauen.

Diversifizierung der Teams

Drupal-Experten sind schwer zu finden. Einige Unternehmen, um schneller voranzukommen, entscheiden sich dafür, das Backend in Drupal aufzubauen und das Frontend an ein Team zu übergeben, das sich auf eine andere Technologie spezialisiert hat, in der mehr Talent verfügbar ist oder die einfacher zu erlernen ist.

Ein weiterer Vorteil, verschiedene Teams an einem Projekt arbeiten zu lassen, besteht darin, Best Practices aus verschiedenen Quellen zu teilen. Dies kann zu viel besseren Endergebnissen führen, als sich auf ein einzelnes Team zu verlassen, das Backend und Frontend baut.

Technologische Abhängigkeit von einer Plattform reduzieren

Je größer das System ist, das auf Drupal aufgebaut ist, desto größer ist die Abhängigkeit davon. Das Abstrahieren von Drupal vom Bedienen des Frontends ermöglicht es Unternehmen, dynamischer beim Wechsel der Frontend-Technologien zu sein, ohne große Drupal-Backend-Systeme neu aufbauen oder umgestalten zu müssen.

Viele Websites, die ein frisches, modernes Erscheinungsbild beibehalten müssen unterziehen sich alle paar Jahre einem Neudesign. Wenn das Frontend vom Backend getrennt ist, ist es viel einfacher, neu zu gestalten. In solchen Fällen könnten die Gesamtkosten der Website niedriger ausfallen, als wenn die Drupal-Website neu aufgebaut würde.

Drupal ist großartig für Headless

Drupal wird sehr oft gewählt, wenn ein Headless-CMS erforderlich ist. Der Grund dafür ist, dass Drupal von Haus aus über die meisten erforderlichen Funktionen verfügt. Es ist eines der ausgereiftesten CMS und hat fantastische APIs.

Die Drupal-Community arbeitet sehr intensiv daran, Drupal zu einem großartigen API-gesteuerten CMS zu machen. 2016 wurde eine “API First” Initiative gestartet. Ihr Ziel war es, die Entwicklungsbemühungen zu koordinieren, um Drupal zu einem vollständig headless CMS zu machen.

Zum Zeitpunkt des Schreibens dieses Artikels wurden enorme Fortschritte gemacht, um es Drupal zu ermöglichen, Inhalte über APIs zu servieren und zu empfangen. 

RESTful-Modul

Seit Drupal 8.2 gibt es ein RESTful-Modul im Drupal-Core, das von Haus aus leicht die Interaktion mit allen Standard-Entitäten ermöglicht, die in Drupal verfügbar sind (Knoten, Benutzer, Taxonomien, Kommentare). Begleitet vom REST-UI- Modul ermöglicht es eine sehr fein abgestimmte Kontrolle darüber, was über die REST-API zugänglich ist und wie.

Anfangs war dieses Modul der Standard für den Aufbau von headless Drupal-Installationen. Es bringt jedoch einige Schmerzpunkte mit sich, die es manchmal ziemlich schwierig machen, damit zu arbeiten.

1. Die zurückgegebenen Datenstrukturen leiten sich standardmäßig von Drupal-Arrays ab, die in JSON umgewandelt, nicht sehr benutzerfreundlich sind und für Frontend-Entwickler schwer zu navigieren sind.
2. Das Abrufen und Filtern von Listen von Entitäten ist etwas mühsam. Für jeden Typ von Liste und Filter muss eine Ansicht in Drupal mit bestimmten Feldern und freigelegten Filtern erstellt werden. Frontend-Entwickler können nicht einfach benutzerdefinierte Listen anfordern.

Trotz der Nachteile war RESTful ein fantastischer Schritt in die richtige Richtung.

JSON:API-Modul

Das JSON:API-Modul wurde mit Drupal 8.8 ausgeliefert. Es hat das REST-Erlebnis mit Drupal massiv verbessert und macht es zu einem unglaublich vielseitigen System, das praktisch jedem CMS auf dem Markt überlegen ist.

Das JSON:API-Modul stellt alle Entitäten in Drupal bereit und ermöglicht einfache Interaktionen, tut dies jedoch auf sehr elegante Weise:

1. Es entspricht dem JSON:API-Standard (https://jsonapi.org/) und macht es für jeden, der sich in eine Drupal-Website integrieren möchte, leicht nachvollziehbar, die Datenstrukturen zu verstehen, ohne dass umfangreiche benutzerdefinierte Dokumentation erforderlich ist.
2. Es ermöglicht das Abfragen von Listen und das Filtern nach Eigenschaften und Feldern von Entitäten, ebenfalls gemäß dem JSON:API-Standard

Die Kernfunktionalität von JSON:API wird durch das JSON:API Extras-Modul erweitert, das eine zusätzliche Konfigurierbarkeit der Endpunkte erlaubt.

Die oben genannten Funktionen machen Drupal effektiv zu einem sehr robusten Backend für Frontend-Anwendungen, wobei alle Datenstrukturen mit der Drupal-UI erstellt werden können, während die REST-Endpunkte automatisch funktionieren, ohne dass Programmierarbeit erforderlich ist.

Ein detaillierter Vergleich der beiden Module ist hier zu finden: https://www.drupal.org/docs/8/modules/jsonapi/jsonapi-vs-cores-rest-module

REST ist tief in das Drupal-System eingebunden

Erwähnenswert ist, dass in den oben genannten Modulen die REST-APIs nicht als nachträglicher Gedanke zu Drupal hinzugefügt werden. Sie sind tief in Drupal-Core eingebunden. Drupal Zugriffskontrolle, Vorverarbeitung von Werten, Hooks, Events usw. All diese werden automatisch berücksichtigt, wenn ein Zugriffspunkt abgefragt wird, genauso wie es bei einer traditionelleren Methode der Fall wäre, wenn ein Drupal-Knoten angefordert wird, indem man eine URL über den Browser aufruft. 

Dies gibt Drupal einen enormen Vorteil gegenüber anderen CMS. Durch die Verwendung von REST können Sie das Standardverhalten weiterhin in jeder gewünschten Weise erweitern und ändern!

Headless vs. progressiv entkoppelt

In diesem Artikel sprechen wir über Headless-Drupal, aber es lohnt sich auch zu erwähnen, dass dies nicht der einzige Weg ist, um einer Drupal-Website Interaktivität hinzuzufügen. Eine weitere Option ist es, eine progressiv (oder teilweise entkoppelte) Drupal-Architektur zu erstellen.

Progressive Entkopplung ist ein Ansatz, der einer typischen Drupal-Konfiguration näher kommt, bei der die erste Serveranfrage von Drupal verwaltet wird, und die zurückgesendete Seite von Drupal zusammengesetzt wird. Auf der Seite betten wir jedoch interaktive Elemente ein, die in Javascript erstellt wurden, welche dann die benötigten Daten abrufen, indem sie eine ebenfalls von Drupal bereitgestellte REST-API aufrufen. 

Dieser Ansatz könnte in den folgenden Szenarien sinnvoll sein:

• Der Großteil der Website ist nicht interaktiv, aber es gibt einige stark interaktive Elemente, die Javascript erfordern.
• Die Website verwendet externe Datenquellen, die dem Benutzer präsentiert werden sollen, aber nicht aus Drupal stammen und nicht gut zu Drupal passen (z. B. sich ändernde Aktienkurse), die direkt von der Quelle durch eine in Drupal eingebettete JS-App abgerufen werden können

Wenn Sie sich nicht sicher sind, welche Lösung Sie wählen sollen, gibt es einen großartigen Beitrag von Dries Buytaert darüber, wie man Drupal 2019 entkoppelt.

Wichtige Überlegungen

Die Entwicklung ist komplizierter und teurer

Eine Headless-Infrastruktur ist komplexer als eine traditionelle Drupal-Website. Dies kann zusätzliche Schwierigkeiten verursachen und die Kosten erhöhen. Wenn man sich für Headless entscheidet, sollte man abwägen, ob die Vorteile die Kosten übersteigen. 

Management mehrerer Teams

In einem Headless-Drupal gibt es zwei separate Komponenten (Frontend und Backend), die entwickelt werden müssen (zumindest zu einem gewissen Grad) in Koordination. Oftmals werden unterschiedliche Entwickler oder Teams (Backend und Frontend) an der Website arbeiten. Manchmal sind dies zwei verschiedene Unternehmen. Dies erfordert Koordination und viel mehr Kommunikation, da Datenmodelle abgestimmt, Endpunkte erstellt und getestet werden müssen. Es ist wahr, dass in Drupal viele von diesen möglicherweise von Haus aus verfügbar sind, aber höchstwahrscheinlich wird es Bedürfnisse für einige benutzerdefinierte geben.

Höhere Gesamtentwicklungskosten

Die Gesamtenwicklungszeit wird wahrscheinlich höher sein, da wir jetzt zwei Systeme bauen, weswegen auch die Entwicklungskosten höher sein werden als die einer vergleichbaren Standard-Drupal-Website, insbesondere unter Berücksichtigung des Koordinierungsaufwands.

Höhere nachfolgende Wartungskosten

Die Wartung eines entkoppelten Systems ist schwieriger. Tests sind wichtiger, wenn man auf REST-APIs angewiesen ist, da Änderungen an einem System es möglicherweise inkompatibel mit dem anderen machen.

Deployments müssen unter Umständen besser orchestriert werden, wenn Änderungen an beiden Systemen auf einmal bereitgestellt werden. Alternativ könnten mehrere Versionen einer API beibehalten werden, was aber auch die Kosten erhöht. All dies könnte die Wartungskosten erhöhen.

Zudem werden Sicherheitsupdates häufiger erforderlich sein, da nicht nur ein, sondern mindestens zwei Systeme gepatcht werden müssen.

SEO (und andere Metadaten-verarbeitende Engines)

Google wird besser und besser darin, Javascript-Inhalte zu indexieren, aber es ist dennoch sicherer und effektiver, alle Inhalte bei der ersten Anfrage an die Haupt-URL bereitstellen zu können. Wenn Ihre Website stark auf Traffic von Suchmaschinen angewiesen ist, könnte ein entkoppelter Ansatz nicht die beste Lösung sein.

Sie sollten auch andere Dienste in Betracht ziehen. Beispielsweise muss für die saubere Teilbarkeit von Inhalten über Facebook und Twitter jedes Stück Inhalt eine separate URL haben und, was ebenfalls wichtig ist, die Basisdaten müssen ohne Javascript verfügbar sein. Zumindest im Moment ziehen Facebook und Twitter, wenn Sie dort einen Link teilen, das Vorschaubild ab, indem sie den Link abfragen, ohne Javascript zu aktivieren. Die Titel-, Bild- und Beschreibungsinformationen sollten daher ohne die Notwendigkeit, Javascript zu aktivieren, verfügbar sein.

Lösungen:

Teilenbarkeit - Rückgabe von Metadateninformationen auf Routen

Für Facebook und Twitter reicht es aus, einen kleinen Teil der Webseiteninhalte auf jeder Route zurückzugeben. Dies kann sogar, und manchmal ist es, durch ein einfaches Skript in einer serverseitigen Sprache (in PHP oder Python usw.) erledigt werden, das je nach abgefragter Route verschiedene Metadaten zurückgibt. Der Server, anstelle einer flachen HTML-Datei mit einer JS-Anwendung, parst ein Skript und gibt identisches HTML zurück, wobei nur die Metatags variieren.

SEO - Serverseitiges Rendering

Für SEO-Zwecke kann auch der oben beschriebene Ansatz verwendet werden, aber typischerweise ist eine andere Methode effizienter. Das Zusammensetzen einer vollständigen Seite mit Inhalten erfordert oft eine erhebliche Menge an Logik, die dann ebenfalls in der Frontendanwendung verfügbar sein muss. Dieselbe Logik zum Zusammensetzen von Seiten sowohl in einer serverseitigen Sprache als auch dann in Javascript für das Frontend zu schreiben ergibt keinen Sinn.

Die Entwickler-Community hat auf React basierende Open Source-Javascript-Frameworks erstellt, die es ermöglichen, Javascript-Anwendungen zu erstellen, die die Seite auf dem Server rendern und dann mit schicker Benutzeroberfläche im Frontend bereichern. Es gibt zwei am häufigsten verwendete Frameworks:

• Nextjs - https://nextjs.org/
• Gatsbyjs  - https://www.gatsbyjs.org/

Beide bieten ähnliche Funktionalität und ermöglichen den Bau von extrem schnellen Websites, die im Backend zusammengesetzt werden und im Frontend super reibungslos funktionieren. 

Aus Drupal-Perspektive ist die Entwicklung eines Headless-CMS identisch für eine typische Single-Page-Anwendung.

Verlust einiger Drupal-Funktionalitäten

Drupal bietet von Haus aus viele Funktionalitäten. Wenn Drupal im Backend bleibt, ist Vieles davon nicht mehr verfügbar. Insbesondere:

• Layout-Management  - Drupal bietet ein hochgradig konfigurierbares Seiten-Layout-Management mit Regionsdefinition und die Fähigkeit, Elemente in verschiedenen Teilen der Seite zu platzieren, ohne sie codieren zu müssen (z. B. Platzieren eines Suchfensters im Header oder eines Menüs im Footer). 
• Kontoverwaltungsbildschirme – Drupal bietet eine Registrierung, Anmelde- und Passwortzurücksetzfunktionalität von Haus aus. Wenn wir beabsichtigen, Benutzern das Registrieren zu erlauben, müssen wir alle Formulare implementieren und sie mit den APIs verbinden.
• Vorschau – Wenn wir Inhalte in Drupal erstellen, können wir als Autor sie vor der Veröffentlichung vorab schauen. In einer typischen Headless-Konfiguration, insbesondere wenn Inhalte über viele Kanäle verfügbar sind, ist die Vorschau von allem nicht verfügbar. Oft fügt der Redakteur Inhalte hinzu, ohne das Endergebnis zu sehen. Falls erforderlich, muss es separat entworfen und erstellt werden, um Redakteuren die Möglichkeit zu geben, ihre Kreationen vorzuschauen.

Zusammenfassung

Headless Drupal ist ein interessanter Ansatz, um funktionsreiche interaktive Websites zu erstellen oder Content-Hubs zu bauen, die verschiedene inhaltskonsumierende Websites und Medien speisen. Es ist jedoch nicht ohne Nachteile und eine sorgfältige Abwägung sollte vorgenommen werden, bevor man diesen Pfad wählt. Hoffentlich gibt Ihnen dieser Artikel genügend Informationen, um eine Entscheidung zu treffen. Wenn nicht, sind wir immer glücklich, Ihr Drupal-Projekt zu beraten.

Geben Sie uns einen Ruf!