Drupal 8 – die Zukunft is entkoppelt

    Digitale Inhalte haben sich zur mehrkanaligen Multiformat-Distribution weiterentwickelt. Heute erwarten wir, diese von überall und zu jederzeit konsumieren zu können. Was bewirkt dies bei WCMS wie Drupal? Erfahren Sie, warum die Zukunft von Drupal entkoppelt ist und welche Bedeutung dahintersteckt.

    Abonnieren Sie unseren Blog

    Eine entkoppelte (decoupled) CMS-Architektur bedeutet, dass zwei oder mehr Systeme vorhanden sind, die miteinander kommunizieren können, ohne aber direkt miteinander verbunden zu sein (gekoppelt). Normalerweise weist ein System sehr geringe Kenntnisse anderer Systeme vor. Welche Vorteile entstehen hier? Eine entkoppelte Struktur ermöglicht die Ausführung von Veränderungen, ohne dass ein anderes System davon beeinträchtigt wird. Das verschafft mehr Flexibilität, wenn es um die Wiederverwendung desselben Contents innerhalb verschiedener Schnittstellen und um ein zukunftssicheres CMS geht, dass sich schnell jeglichen neu entstehenden Kanälen anpassen wird.

    Anhand einer entkoppelten Architektur werden ebenso die Zuständigkeiten zwischen beiden Ebenen aufgeteilt (siehe nachfolgendes Bild). Das System, das die Inhalte konsumiert, muss sich nicht um Datenarchitektur, Sicherheit, Infrastruktur und andere Faktoren sorgen. Und der Datenanbieter (der Webservice, in unserem konkreten Fall die „entkoppelte Drupal“-Instanz, in der ein Content Editor arbeitet) muss sich nicht um die Frontend-Technologie, das Layout, usw., kümmern.

    Wenn wir dies in das typische Drupal-Setup übertragen, bedeutet es, dass wir im Grunde eine Linie zwischen der Präsentationsebene und das Content-Management von Drupal ziehen (Frontend kontra Backend). Dies wird auch "headless CMS" (kopflos) genannt, in diesem Fall "headless Drupal", da Benutzer normalerweise nicht den "Kopf" oder die Themes der Drupal CMS-Installation einsehen können.

    The future of Drupal is decoupled and what it means for authors, administrators and users.

    In dieser Konfiguration fungiert Drupal nur als Datenanbieter (Content-Service). Über Webdienste (eine Art von Kommunikationsmechanismus zwischen verschiedenen Softwareanwendungen) stellt es Inhalte in seinem Rohformat bereit. Es liegt an den Verbrauchern dieser Daten (den Systemen, die die Webdienste verwenden), die Daten zu nutzen und visuell darzustellen. Als Beispiel liefert die Drupal-Instanz einfache Daten über Ereignisse über einen Webservice. Zwei potenzielle Konsumenten könnten eine iOS-Kalenderanwendung und eine Website sein, die alle Ereignisse auflistet. In diesem Fall rufen beide Konsumenten (App und Website) rohe (Text-) Daten ab. Sie müssen das jeweilige Styling anpassen (die Informationen, für die sie programmiert sind, filtern) und einsetzen (z. B. HTML-Markup erstellen, CSS anwenden, usw.).

    Weshalb sollte das entkoppelte Drupal verwendet werden?

    Bis zur Version 7 von Drupal (2009) war der Verbrauch von Online-Inhalten weitgehend auf Browser auf Desktop-Computern beschränkt. Mit dem Aufkommen von Touchscreens und tragbaren Geräten wie Smartphones und Tablet-Computern hat der mobile Online-Zugang den Desktop auf vielfältige Weise Schritt für Schritt eingeholt und sogar überholt, was zu einer Verlagerung digitaler Kanäle hin zu einem "Mobile-first" -Ansatz geführt hat. Die Standardpräsentation von Content war nicht mehr auf die großen Computerbildschirme zugeschnitten, sondern für alle Arten von Bildschirmen optimiert: von Telefonen über Tablets bis zu Fernsehgeräten und allem dazwischen. Unsere höchste Priorität ist und bleibt die Bereitstellung von voll funktionsfähigem Content, das für allen Bildschirmauflösungen optimiert wurde.

    In den letzten Jahren sehen wir allerdings eine große Anzahl alternativer Möglichkeiten zur Darstellung von Inhalten. Diese reichen von verschiedenen JavaScript-Frameworks wie AngularJS, ReactJS, Vue.JS .., über nativen Android- oder iOS-Mobilanwendungen, bis hin zu kleinen Widgets, die nur kleine Teile aufnehmen um diese im Rahmen anderer Schnittstellen bereitstellen.

    Wenn wir dies mit Drupal erreichen wollen, müssen wir das Content-Modell von der Template-Engine (Twig in Drupal 8) vollständig entkoppeln, damit Inhalte dem gewählten Konsumentensystem zugänglich gemacht werden können.

    Dieser Grundsatz basiert auf das "COPE"-Prinzip: "Einmal erstellen, überall veröffentlichen" (“Create Once, Publish Everywhere“).  Das ist ein dem Single-Source-Publishing ähnliches Konzept, bei dem alle Inhalte in ein zentrales Repository (Drupal Backend) verwaltet und über alle Kanäle verteilt werden (entweder „pushed“ oder „pulled“, wenn die Daten benötigt werden).

    Eine Zukunft durch API-first oder eher  „decoupled by design“?

    Innerhalb von Drupal 8, haben wir bereits grundlegende Unterstützung für REST-Dienste für den Datenaustausch bereitgestellt. Die REST-API ist jedoch schwer einzurichten und zu konfigurieren. Um vollständig entkoppelt zu sein, braucht Drupal noch etwas mehr Entwicklung, und es gibt zwei gemeinschaftliche Initiativen, die derzeit auf diesem Thema aufbauen.

    Die wichtigste und konkreteste ist derzeit die von Wim Leers geleitete Initiative „API-first". Die Mitwirkenden von API-first arbeiten intensiv daran, die derzeit verfügbare REST-API zu verbessern, die sie als "Best-in-Class" bezeichnen. Mit mehr Flexibilität sollen neue Arten der Integration, eine progressive sowie eine vollständige Entkopplung unterstützt werden. Das Endziel ist, alle Daten innerhalb von Drupal in beiden verfügbar zu machen:

    • Ein Weg mit RESTfully, wobei JSON oder ein anderes Format eines REST-Services über den Standard hinaus unterstützt wird
    • Ein Weg ohne RESTfully, wie zum Beispiel GraphQL oder CouchDB
    • Verwendung eines beliebigen Authentifizierungsmechanismus für Websites und native mobile Apps wie z. B. OAuth2 und Cookie.

    In den nächsten Releases von Drupal wird aus dieser Initiative heraus viel bewegt werden. Die meisten new functionalities streben nach einem "stabilen" beigesteuerten Modul, so dass dieser in den Drupal-Kern eingebaut werden kann. Das bedeutet auch, dass dieser für alle Drupal-Installationen verfügbar sein muss, die als Zusatzmodul hinzugefügt werden. Wenn das „Core Comittee“ (Kern-Kommitee) entscheidet, dass die Funktionalität in den Kern übergehen kann, steht fest, dass bereits eine stabile Version getestet wurde und auch einsatzbereit ist.

    Durch alle zuvor erwähnten Punkte wird es Drupal ermöglicht, als „kopflosen Datenanbieter“ eingesetzt zu werden. Begonnen wird allerdings stets mit einer gekoppelten Installation. Besteht die Möglichkeit, dass sich Drupal bei all dem Elan, der mit der Entkopplung einhergeht, eher auf eine reine API als auf eine API-orientierte Architektur oder auf eine vollständig entkoppelte Architektur konzentriert? Es besteht sicherlich einen Markt für diesen Ansatz – sowohl für die zuvor erwähnte Frontend-Entwicklung, als auch für die Administration im Backoffice.

    Eine zweite vom Kommitee genehmigte Initiative sieht eine Möglichkeit vor, die aktuellen Backoffice-Seiten zu modernisieren, die in die Jahre gekommen waren und erst seit Kurzem adaptiert und  überarbeitet wurden. Ihr aktueller Ansatz (oder Proof-of-Concept) besteht darin, diese Seite durch eine einseitige React-Anwendung zu ersetzen. Es stellt ein frühes Stadium dar – In diesem Rahmen sind noch zahlreiche Aufgaben zu erledigen, um dies dem Drupal-Kern hinzuzufügen (das Team geht die Sache Schritt für Schritt an und versucht progressiv daraus zu lernen). Interessant ist in diesem Rahmen sicherlich zu sehen,  dass  das Komitee solch eine Entscheidung trifft.

    Zu erwarten ist, dass einige auftauchenden Fragen innerhalb des Vorgangs beantwortet werden:

    • Was passiert mit der aktuellen Templating-Engine (Twig)? Funktionieren sowohl Twig als auch die React-Anwendung nebeneinander? Wird Twig "optional" sein?
    • Es existieren Hunderte an beigesteuerten Modulen. Müssen diese einen Support für eine "entkoppelte" Schnittstelle vorweisen, oder werden alle auf Twig zurückfallen?
    • Ist es eine gute Idee, eine feste Auswahl im Rahmen des Kerns für ein Framework (React) zu treffen?
    • Wird es ein vollständig entkoppeltes Drupal-Installationsprofil geben?

    Ziel ist es letztlich, eine entkoppelte CMS-Architektur zu schaffen, die aber dennoch eine monolithische Erfahrung bietet. Benutzern, Autoren und Administratoren ist es egal, ob eine Website entkoppelt, von Drupal gerendert oder statisch ist. Sie möchten, dass ihre Erfahrung so nahtlos und einheitlich wie nur eben möglich ist, während Entwickler eine maximale Flexibilität wünschen.

    Veröffentlicht auf    Zuletzt aktualisiert am 16/08/2018

    #Drupal, #Content Management, #Digitale Strategie, #Webentwicklung

    Über den Autor

    Kevin is Drupal Web Developer and Consultant at Amplexor based in Belgium. Kevin is an Acquia Certified Developer with over 6 years of experience in planning, development, maintaining Drupal websites and leading development teams in Drupal. He has also volunteered at the organization of the yearly Belgian DrupalCamp event.

    SUBSCRIBE TO OUR BLOG