Optimierung von Decoupled Drupal: Custom Elements UI ermöglicht es Frontend-Entwicklern, Drupal’s Datenverarbeitung für API-Responses zu konfigurieren und so den Output präzise anzupassen.
Das Custom Elements-Modul ist ein wesentlicher Baustein für Decoupled Drupal-Anwendungen sowie ein elementarer Bestandteil des Lupus Decoupled Drupal Stack.
Im Gegensatz zu anderen Lösungen, bei denen das Frontend individuelle Listen von Entities oder einzelne Entities anfordert, ist Drupal mit dem Custom Elements-Modul und dem Begleitmodul „Lupus CE Renderer“ in der Lage, API-Responses zu generieren, welchedie vollständigen Daten beinhalten, die zum Rendern einer Seite benötigt werden. Dieser Ansatz reduziert die Komplexität des Frontends und die Anzahl der Queries an das Backend erheblich.
Die neu eingeführte Custom Elements Version 3 bietet erhebliche Verbesserungen und ermöglicht Frontend-Entwicklern die Anpassung des API-Outputs. Genau um dies zu erreichen wurde Custom Elements UI entwickelt. Es basiert auf dem Konfigurationssystem von Drupal, welches es Site-Buildern ermöglicht, die Art und Weise, wie Entities in API-Responses verarbeitet werden, im „View Mode“ anzupassen.
Zu diesem Zweck führt das Modul eine neue „Custom Element Field Formatters“ API ein, die es anderen Modulen ermöglicht, wiederverwendbare Data Formatting Plugins bereitzustellen. Dadurch können Drupal-Site-Builder den API-Output anpassen, indem sie geeignete Data Formatting Plugins auswählen und konfigurieren. Der Prozess spiegelt Drupal Core's Field Formatters und Entity Display Konfiguration wider, zielt jedoch speziell auf die Anpassung der API-Responses ab. Folglich können Frontend-Entwickler API-Responses allein über die Drupal-Konfiguration anpassen, sodass keine benutzerdefinierte Entwicklung erforderlich ist.
Decoupled Drupal-Sites sind eine beliebte Methode zum Erstellen ambitionierter Webanwendungen. Wenn das Frontend jedoch mit benutzerdefinierten REST-Endpoints auf der Drupal-Backend-Seite gekoppelt wird, kann die Entwicklungseffizienz aufgrund des entstehenden Kommunikations-Overheads zwischen dem Backend und dem Frontend-Entwickler leiden:
Traditionell würden Frontend- und Backend-Entwickler beim Entwurf der Lösung zusammenarbeiten und gemeinsam die API-Spezifikationen definieren, die für eine nahtlose Integration zwischen den Frontend- und Backend-Komponenten erforderlich sind. Während anschließend Frontend- und Backend-Teile der Anwendung parallel entwickelt werden können, kann die Lösung erst dann endgültig getestet werden, wenn beide Parteien ihre Arbeit abgeschlossen haben. Wenn während der Entwicklung ungeplante Probleme auftreten oder Fehler behoben werden müssen, müssen sich Entwickler häufig abstimmen und warten, bis „die andere Seite“ der Anwendung angepasst wird. Dies führt häufig zu Verzögerungen im Entwicklungsprozess.
Umgekehrt entfällt der Kommunikations- und Koordinationsaufwand, wenn der Frontend-Entwickler in die Lage versetzt wird, den Data Processing Aspekt der Applikation anzupassen. Diese Autonomie ermöglicht es dem Frontend-Entwickler, die gesamte Lösung bis zur Fertigstellung unabhängig zu erstellen, zu testen und zu iterieren, ohne sich mit anderen Teammitgliedern zu synchronisieren oder auf sie warten zu müssen.
Aus diesem Grund wurde der Plan erstellt, Frontend-Entwicklern die Möglichkeit zu geben, die API-Responses ausschließlich durch die Konfiguration von Drupal anzupassen – über die Custom Elements UI.
Um dieses Ziel zu erreichen, muss das System vielseitig genug sein, um verschiedene Use-Cases abzudecken. Nach gründlicher Analyse haben wir uns entschieden, das bewährte Konzept der Field Formatters und Entity Display Konfiguration von Drupal Core zu übernehmen und es an maßgeschneiderte API-Responses anzupassen. Neben den bestehenden „Formular“- und „View“-Displays von Drupal wurde eine neue Art von „Entity Display Object“ und Konfigurationselement eingeführt, das „Custom Element Display“. Anstatt „Field Formatter“ zu konfigurieren, führt das Custom Element Display „Custom Element Field Formatters“ ein und nutzt diese. Zusammen mit einigen nützlichen „Custom Element Field Formatter“-Plugins, die vom Modul selbst bereitgestellt werden, und der Möglichkeit, die von ihnen bereitgestellten Datenstrukturen zu „flatten“, hat sich das Konzept als leistungsstark erwiesen, und erfüllt dadurch allgemeine Anforderungen.
Zur Validierung der Lösung hat drunomics den neuen konfigurationsgesteuerten Ansatz in seine interne Drupal-Distribution integriert. Zuvor basierte diese Distribution auf benutzerdefinierten Custom-Element-Processor-Plugins. Diese wurden durch vielseitige, wiederverwendbare “Field Formatters” und Konfigurationen ersetzt. Konsequenterweise kann das Team von drunomics jetzt neue Decoupled Drupal-Sites mit unterschiedlichen Datenmodellen entwickeln, ohne dass ein Backend-Entwickler intervenieren muss.
Schließlich wurde die Lösung in die erste stabile Version von Lupus De Coupled Drupal integriert und ermöglicht Frontend-Entwicklern die schnelle Erstellung anspruchsvoller, Decoupled Experiences durch die Kombination von Drupal mit modernen Frontend-Frameworks.
Bei der Implementierung der Lösung standen wir vor drei Hauptherausforderungen:
1) Eine große Herausforderung bestand darin, den neuen Custom Element Field Formatter zu implementieren und gleichzeitig die Kompatibilität mit vorhandenen Core Field Formatters und deren UI Konfigurierbarkeit zu wahren. Wir begannen mit der Rekonstruktion der Core View-Display UI und verfeinerten sie dann schrittweise. Wir haben Core Field Formatters integriert, indem wir eine „Derivative Plugin“-Implementierung entwickelt haben, die es uns ermöglichte, diese Core Formatters als „Custom Element Field Formatters“ verfügbar zu machen und so die Funktionalität beizubehalten und gleichzeitig neue Funktionen einzuführen.
2) Der neue konfigurationsgetriebene Ansatz steht natürlich im Widerspruch zum zuvor verwendeten codegesteuerten Ansatz. Dennoch sollten die Flexibilität und die Wahlmöglichkeiten, in bestimmten Situationen codegesteuerte Ansätze zu nutzen, erhalten bleiben. Dieser Herausforderung wurde durch die Einführung der neuen Konfigurationsoption„force automatic-processing“ begegnet, die wiederum wie der vorherige codegesteuerte Ansatz funktioniert und so die Flexibilität ermöglicht und die Aktualisierung für bestehende Websites vereinfacht.
3) Das Rendern von View-Modes mit aktiviertem Layout-Builder in einer API-Response für Custom Elements wird vom Modul bereits unterstützt, bietet aber noch eine weitere Möglichkeit zum Rendern. Der hierfür erforderliche Ansatz musste komplett überarbeitet und in den konfigurationsgesteuerten Ansatz integriert werden, sodass er nahtlos funktioniert und eine anständige UX für Website-Ersteller bietet.
Die neue Version des custom_elements-Modul führt zu erheblichen Produktivitätssteigerungen. Das Modul ist Open Source und für jeden verfügbar, der entweder seine eigene API für eine Decoupled Drupal CMS-Implementierung verwenden möchte oder auf die Referenzimplementierung Lupus Decoupled Drupal (das ebenfalls Open Source ist und auf drupal.org veröffentlicht wird) zurückgreifen möchte.
Diese Lösung fügt sich nahtlos in die Starshot-Mission von Drupal ein, die darauf abzielt, Site-Buildern die Möglichkeit zu geben, mit Drupal weitaus mehr zu erreichen. Wir sehen, dass Lupus Decoupled Drupal in Kombination mit der neuen Custom Elements UI und einem kommenden Experience Builder sehr gut positioniert ist, um die Anforderungen von Frontend-Entwicklern an ein flexibles und dennoch leistungsstarkes Backend-CMS zu erfüllen. Dieser Ansatz hat das Potenzial, Drupal dabei zu unterstützen, Marktanteile in der sich entwickelnden Web-Development-Landschaft zurückzugewinnen.
