Die Abbildung zeigt ein Beispiel, das eine Drupal-änhliche Antwort zurückliefert, mit dem speziellen _nest-Feld von FakeQL

Headless Drupal, decoupling Drupal

Josef DabernigMärz 2019

Drupal wurde in der Vergangenheit oft und zu Recht als klassisches CMS bezeichnet. In den letzten Jahren hat sich Drupal aber auch in der Headless- und Decoupled-Szene einen Namen gemacht. Viele Wege führen bekanntlich nach Rom, und so bietet auch der modulare Ansatz von Drupal vielschichtige Möglichkeiten zur Entkoppelung.

Drupal ist API-First

Seit Drupal 8 gibt es verschiedene Schnittstellen, um die Entkopplung in mehreren Stufen zu vollziehen. Als klassisch monolithisches CMS betrieben, sind Backend und Frontend eng miteinander verzahnt und ermöglichen die effiziente Umsetzung von Webprojekten. Mithilfe der integrierten API-Schnittstellen wie REST, JSON:API und GraphQL können Teile der Drupal-Weblösung «Progressively Decoupled» werden. Die spezifischen Seitenbereiche verhalten sich dann wie eine entkoppelte App, welche auf das Backend via Schnittstelle zugreift. Im vollentkoppelten Betrieb konsumieren dann ein oder mehrere Frontends die Daten aus Drupal, um sie in einer eigenständigen Website bzw. Applikation darzustellen.

Die Website ist oft nur der Start

Insbesondere mithilfe der graduellen Ausbaufähigkeit von Drupal kann sich die Weblösung dynamisch weiterentwickeln. Neue Anforderungen zur Integration einer PWA, Anbindung einer React Native App oder die Auslieferung der Webinhalte an andere Drittsysteme können durch die modularen Schnittstellenfähigkeiten von Drupal laufend ergänzt werden. So kann sich die Website in eine Landschaft von Webapplikationen weiterentwickeln, ohne dass sich das Kernsystem von seinen primären Aufgaben verabschieden muss. Die strukturierte Erfassung von Inhalten mittels einer ansprechenden Redaktionsoberfläche mit feingranularen Berechtigungen und anpassungsfähigen Workflows bilden das Herz der meisten modernen Drupal-Seiten. Komplexe Übersetzungsworkflows oder integrierte E-Commerce-Anwendungen lassen sich optimal darauf aufbauen.

To decouple or not?

Coupled, progressively decoupled oder fully decoupled? Diese Frage wird in letzter Zeit immer häufiger gestellt. Will man ein klassisch monolithisches Drupal umsetzen? Oder bloss Content über eine Schnittstelle publizieren? Oder gar eine Mischform? Gerade im Hinblick auf die kontinuierliche Weiterentwicklung und Pflege der Weblösung macht es Sinn, hier entsprechend eine Entscheidungsgrundlage zu bilden.

Vorteile:

Verteilte Use Cases können umgesetzt werden (Content Syndication, Omni-Channel Publishing bzw. «COPE – Write Once Publish Everywhere»).
Weitere Devices können bespielt werden (Apps, Conversational Content, Augmented & Virtual Reality).
Developer Needs können befriedigt werden (Pull statt Push im Frontend; Isomorphic JavaScript).

Nachteile:

Knifflige Fragen müssen gelöst werden (Image Styles, Routing, Schemas).
Verlorene Out-Of-The-Box-Features von Drupal müssen zusätzlich implementiert werden (Quickedit, In-site Preview).
Zusätzliche Komplexität entsteht (Frontend-Stack, Schnittstellen, Hosting, Authentifizierung).

Wann macht es Sinn?

Mehrere Frontends sollen von einem Backend bespielt werden.
Eine Trennung von Frontend und Backend macht Sinn z. B aufgrund der Grösse des Teams bzw. der Organisation.
Das moderne Frontend wird z. B rein in JavaScript umgesetzt und erfordert eine standardisierte Schnittstelle.
Das Backend bzw. das Frontend sollen unabhängig voneinander weiterentwickelt werden können.
Decoupled-Drupal-Lösungen sind bereits stark am Markt vertreten.

Wer sich vertiefen möchte, bekommt im Buch «Decoupled Drupal in Practice» von Preston einen guten Überblick. Die aktuelle Weiterentwicklung kann man bei der Drupal Core API-First Initiative mitverfolgen.