Plugins in Webanwendungen

Zeit und Verfügbarkeit spielen in der Softwareentwicklung eine stetig wichtiger werdende Rolle. Dabei ist es wichtig, Software in kürzester Zeit zur Verfügung zu stellen, um wettbewerbsfähig zu bleiben. Bei Webanwendungen bedeutet dies: Eine Webanwendung muss erreichbar sein. Aber wie sieht es mit Updates aus?

Plugins in normalen Anwendungen

Bei verschiedensten Anwendungen ist es deswegen gang und gäbe, Funktionalitäten über Plugins bereitzustellen. Plugins dienen als Mittel, eine Software um „optionale Funktionalitäten“ zu erweitern. Sie dienen auch dazu, durch ständige Änderungen ein sicheres Kernsystem beizubehalten. Dabei können Plugins von den gleichen Entwicklern oder sogar von Dritten erstellt werden.

Als Beispiel dient hier die Entwicklungsumgebung Eclipse: Eclipse ist ein Programm, welches die Entwicklung mit Java (und weiteren Programmiersprachen) vereinfacht. Reichen die Grundfunktionalitäten nicht aus, können über den eingebauten Marketplace von Designänderungen bis Sprachunterstützungen von Programmiersprachen verschiedenste Änderungen vorgenommen werden:

(Dabei kann es passieren, dass die Anwendung trotzdem neu gestartet werden muss, damit die Änderungen wirksam werden! Dennoch ist so ein Update relativ schnell.)

Aber lässt sich so ein System in Webanwendungen ebenfalls umsetzen?

Um so ein Plugin-System in Webanwendungen zu ermöglichen, muss verstanden werden wie ein Plugin-System denn funktioniert. Hierfür kann Eclipse als „Beispiel“ betrachtet werden; ein solches System besteht von außen betrachtet aus diesen Komponenten:

1. Ein lauffähiges Kernsystem,
2. Plugin-Schnittstellen (UI und Logik),
3. ein Mechanismus, um Plugins zu laden und
4. Plugins

Eine lauffähige, „normale“ Webanwendung zu erstellen, sollte kein Problem sein (1). Ebenso können an verschiedenen Bereichen Container oder Listen für Plugins definiert werden (2.1):

Auch Schnittstellen können von einer Webanwendung bereitgestellt werden, zum Beispiel REST (2.2). Die Problematik entsteht erst bei der Einbindung von Plugins (3) und der Plugins selbst (4). (Weiterhin wäre es für manche Webanwendungen schön, diese bei der Installation eines Plugins nicht neustarten zu müssen.)

Als Architekturmuster für Webanwendungen kann folgender Entscheidungsgraph hinzugezogen werden:

Je nach Zustand des Entwicklungsprojekts oder des Datenaustauschs von Widgets können verschiedene Ansätze gewagt werden.

Betrachtet man Plugins als separate Widgets innerhalb einer Webanwendung / Weboberfläche, ist die JavaScript-Spezifikation Web Components ein möglicher Ansatz.

Dynamische Widgets mit Web Components

Die Web Components sind eine JavaScript-Spezifikation, welche aus drei Technologien zusammengesetzt sind:

• Custom Elements: Die Erstellung eigener HTML-Elemente (also auch Tags). Diese ersetzen Strukturen wie <div id=“customer-list“> durch <customer-list> und können einfacher mehr Funktionen bieten
• Shadow DOM: Ein gekapselter DOM für die Child-Elemente eines HTML-Elementes
• HTML-Templates: Die Erstellung von HTML-Elementen als befüllbare Strukturen, um diese in anderen Anwendungen wiederzuverwenden

Web Components sind in verschiedenen JavaScript-Frameworks erstellbar. Neben VanillaJS können diese beispielsweise in React (Hyperlink: https://reactjs.org/docs/web-components.html), Vue (Hyperlink: https://cli.vuejs.org/guide/build-targets.html#web-component) und Angular (Hyperlink: https://angular.io/guide/elements) erstellt werden. Dabei können neben einfacheren Strukturen (wie Buttons oder Listen) auch komplette (Micro-)Apps (also auch Plugins!) als Web Component erstellt werden. Daraus ergeben sich verschiedene Vor- und Nachteile:

Die technologieübergreifende Entwicklung ist ein großer Vorteil der Web Components. Widgets können in verschiedenen Frameworks erstellt und in anderen eingebunden werden, da Web Components als JavaScript-Datei (.js) exportiert werden. Durch die Einbindung von Web Components als einfache HTML-Elemente in externen JavaScript-Dateien können diese sogar zur Laufzeit (über eine Server-Config) eingebunden werden. Es muss also zur Kompilierzeit nicht mal klar sein, dass ein bestimmtes Plugin überhaupt existiert (hier kommen Schnittstellen ins Spiel). Die HTML-Elemente werden über einfache DOM-Manipulationen hinzugefügt und die Skripte (eventuell per Lazy-Loading) zur Laufzeit nachgeladen. Eventuell empfiehlt es sich, Web Components zu bundlen.

Damit auch alle Features einer bereitgestellten Komponente separat funktionieren, könnten im Worst Case Bibliotheken mit der Web Component zusammen bereitgestellt werden (bei Angular). Das verursacht relativ große JavaScript-Dateien, die beim Client eingebunden werden müssen:

170 KB erscheinen relativ viel für ein Angular-Widget, in dem nur „Hello World“ steht. 170 KB stellen an sich kein Problem dar, bei deutlich mehr Plugins können diese aber dann doch Ladezeiten erzeugen. Das ist vor allem dann ärgerlich, wenn alle Web Components die gleichen Bibliotheken importieren. Hier könnten einmalig global bereitgestellte Bibliotheken aushelfen (und die Entkopplung der Bibliotheken aus der Web Component).

Schlussbetrachtung

Die Umsetzung einer dynamischen Webanwendung ist keine Frage der richtigen Technologie, sondern der richtigen Architektur.  Je nach Use Case empfehlen sich verschiedene Architekturmuster. Dabei muss evaluiert werden, welcher Ansatz (oder mehrere) sich für eine Anwendung lohnt.

Dennoch bieten Web Components einen guten Mehrwert für jede Webanwendung. Sind keine aufwendigen, zur Kompilierzeit unbekannten, technologieübergreifenden (et cetera) Widgets notwendig, können auch einfache Elemente erstellt werden. Diese könnten sogar in anderen Anwendungen wiederverwendet werden.

Co-Autor: David Wichmann hat diesen Blogbeitrag im Rahmen seiner Thesis verfasst. Als Betreuer stand ihm Maximilian Wesener zur Seite.