It’s #FrontendFriday – Der Status Quo zu Microfrontend-Frameworks
Yeah, es ist #FrontendFriday!
Im heutigen Blogpost möchte ich euch den Status Quo zu Microfrontend-Frameworks aufzeigen. In unserer Webfrontend-Forschungsgruppe beobachten wir ständig neue Technologien und Architekturen – so auch seit dem ersten Hype um das Buzzword Microfrontend. Im Rahmen der Evaluierung von Microfrontend-Frameworks konnte ich feststellen, dass sich besonders zwei Frameworks in den letzten Jahren als die Microfrontend-Frameworks etabliert haben. Diese möchte ich euch nun vorstellen.
Eines vorweg: seit dem Beginn der Microfrontends ist die Seite micro-frontends.org von Michael Geers ein must read, wenn es darum geht ein grundlegendes Verständnis von der Microfrontend-Thematik zu erhalten.
Geers ist auch Autor des bekannten Buches „Microfrontends in Action“, welches ich ebenfalls nur wärmstens empfehlen kann.
Bevor man sich jedoch mit der Frage beschäftigt, welches Microfrontend-Framework für ein Projekt geeignet ist, muss man sich zwingend vorher die Frage stellen:
Wird ein Microfrontend wirklich benötigt?
(„wir wollen“ !== „wir brauchen“)
Dies ist nur der Fall, wenn alle vier Fragen mit „ja“ beantwortet werden.
- Generell: Steht im Projekt der Nutzen durch unabhängig voneinander deploybaren Einheiten in einem gesunden Verhältnis zum Integrationsaufwand?
- Ist absehbar, dass das Projekt zukünftig in mehreren Teams (min. 3 Teams mit jeweils mind. 2 Entwickler:innen) im Frontend umgesetzt wird?
- Ist der Einsatz von verschiedenen Technologien (Frameworks/Libraries) im Frontend notwendig – falls ja, warum?
- Wird auch im Backend eine vertikale Architektur (Microservices) eingesetzt?
Wird eine der Fragen mit „nein“ beantwortet, muss man zwangsläufig kritisch in Frage stellen, ob eine Microfrontend-Architektur Sinn macht, d.h. wirtschaftlich und nachhaltig ist.
Verbreitung der Microfrontend-Frameworks
Quelle:https://www.npmtrends.com/qiankun-vs-@teambit/bit-vs-single-spa-vs-piral-vs-oc-vs-@luigi-project/client-vs-frint-vs-node-tailor-vs-puzzle.js
Mittels npm-trends.com lässt sich sehr gut ablesen, dass das Framework single-spa mit Abstand am häufigsten heruntergeladen und somit am weitesten verbreitet ist. An zweiter Stelle steht qiankun, welches auf single-spa aufbaut, und noch als „Newcomer“ gilt.
Was unterscheidet die beiden Frameworks?
qiankun baut auf single-spa auf – das grundlegende Microfrontend-Setup unterscheidet sich jedoch. Deshalb ist je nach Anforderungen single-spa oder qiankun zu wählen.
Beide Frameworks lösen das Problem der Microfrontends sehr gut – jedoch auf verschiedene Weisen. Was genau die Unterschiede sind, wird in der folgenden Tabelle erläutert und soll bei Auswahl des Anwendungsfalls helfen.
| single-spa | qiankun | |
|---|---|---|
| Leitspruch | „javascript router for front-end microservices“ | „Probably the most complete micro-frontends solution you ever met“ |
| „Micro-Granularität“ | Fein: Module-Loader (Microservice-Ansatz aus dem Backend bis ins Frontend). → Das Teilen von Common Libs, Funktionen und Variablen ist einfach(er). Keine strenge Entkoppelung. |
Grob: App-Loader (der als „allgemein bekannte“ Microfrontend-Ansatz). → Die Micro-Apps sind als getrennte, entkoppelte Anwendungen zu verstehen. |
| Entry-Mode | JS Entry (über JS-Imports) SystemJS |
HTML Entry (über HTML-Tags) |
| JavaScript Sandbox | Nein | Ja |
| Style Isolation | Nein | Ja |
| Global State verfügbar | Nein | Ja |
| Module Federation | Ja (Webpack 4 und 5) | Nur unter Webpack 5 Apps |
| Visualisierung |  |
|
Zusammengefasst kann man sagen, dass bei einer „feinen“ Microfrontend-Architektur auf Modul-Basis single-spa das richtige Framework ist, und bei einer „groben“ Microfrontend-Architektur mit gentrennten, eigenen Apps qiankun das Mittel der Wahl ist.
