Drupal wird oft und gerne als CMS dargestellt und das vollkommen zu Recht. Doch Drupal ist vor allem auch ein Framework und konnte sich daher in den vergangenen Jahren auch im Headless- und Decoupled-Bereich etablieren. Kein Wunder, denn schließlich bietet Drupal Unmengen an Möglichkeiten zur Entkoppelung.
Drupal agiert als API-Schnittstelle
Wussten Sie, dass Drupal mehrere Schnittstellen bietet, um die Entkopplung gegliedert zu vollziehen? Ja Sie lesen richtig, denn als klassisch und kompakt betriebenes CMS sorgt Drupal dafür, dass Back-End und Front-End eng miteinander vereint sind, sodass die effiziente Umsetzung von Webprojekten möglich ist. Mittels der Einbindung von API-Schnittstellen wie beispielsweise REST oder GraphQl können Teile der auf Drupal basierenden Weblösungen nach und nach Decoupled, also entkoppelt werden. Dabei verhalten sich die spezifischen Bereiche der Webseite genauso wie eine entkoppelte Applikation, welche mittels Schnittstelle auf das Back-End zugreift. Im vollentkoppelten Zustand greifen dann ein oder auch mehrere Front-Ends direkt auf die Daten aus Drupal zu, um so eine vollkommen eigenständige Webseite oder App aufzuzeigen.
Dank der enormen Ausbaufähigkeit von Drupal kann sich Ihre Weblösung hinsichtlich ihrer Dynamik enorm weiterentwickeln. So lassen sich neue Integrationsanforderungen einer Progressive Web App, kurz auch PWA zum Beispiel laufend durch die uneingeschränkte Schnittstellenfähigkeiten von Drupal ergänzen. Gleiches gilt beispielsweise auch für die Auslieferung von Webinhalten an Drittsysteme – auch hier leisten die modularen Schnittstellen von Drupal hervorragende Arbeit. Auf diese Art und Weise können sich Webseiten in einem großen Areal von Webapplikationen kontinuierlich weiterentwickeln, ohne dass sie sich dabei im Kernsystem von gewohnten und vorrangigen Aufgaben distanzieren müssen.
Entkoppeln, nicht entkoppeln oder doch lieber auf eine Mischform zurückgreifen?
Viele unter uns beschäftigen sich hinsichtlich dieser Thematik mit zahlreichen Fragen bezüglich der Umsetzung. Möchte ich auf die klassische monolithische Drupal Form zurückgreifen oder lediglich Content via unterschiedlicher Schnittstellen veröffentlichen? Vielleicht möchten Sie aber auch von einer Mischform Gebrauch machen? Um hier auf einen Nenner zu kommen, sollten Sie unbedingt eine entsprechende Entscheidungsgrundlage auf Basis von Vor- und Nachteilen zu Rate ziehen:
Pro
- Es lassen sich verteilte Anwendungsfälle (Use cases) wie zum Beispiel Content-Syndication umsetzen
- Es können problemlos weitere Hilfsmittel wie beispielsweise Applikationen, Virtual Reality und Co. bespielt werden
- Entwicklungsanforderungen können optimal befriedigt werden
Contra
- Komplizierte Fragen zu Themen wie Image Styles, Routing und Co. müssen optimal gelöst werden
- Verlorene Out-of-the-Box-Funktionen, kurz auch OOTB-Funktionen müssen zusätzlich entwickelt werden
- Aufgrund zusätzlicher Schnittstellen, Hosting, Authentifizierung und Co. entsteht eine zusätzliche Komplexität
Wann ist der beste Zeitpunkt um Drupal als Headless- und Decoupled-CMS einzusetzen?
Diese Art von Umsetzung macht vor allem dann Sinn, wenn:
- mehrere Front-Ends von einem Back-End bespielen lassen möchten
- das moderne Front-End aufgrund von Umstrukturierungen eine standarisierte Schnittstelle benötigt
- das Back-End und Front-End unabhängig voneinander weiterentwickelt werden sollen
- das Team bzw. die Organisation so groß ist, dass eine Trennung von Front-End und Back-End schon fast unabdingbar ist