Projektziele und -ergebnisse

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.