Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Vergleich von Mikro-Frontends mit alternativen Architekturen

Wie bei allen Architekturstrategien muss die Entscheidung für die Einführung von Mikro-Frontends auf Bewertungskriterien basieren, die sich an den Prinzipien Ihres Unternehmens orientieren. Mikro-Frontends haben Vor- und Nachteile. Wenn sich Ihr Unternehmen für den Einsatz von Mikro-Frontends entscheidet, müssen Sie über Strategien verfügen, um die Herausforderungen verteilter Systeme zu bewältigen

Bei der Auswahl einer Anwendungsarchitektur sind Monolithen, n-Tier-Anwendungen und Microservices in Kombination mit einem SPA-Frontend (Single Page Application) die beliebtesten Alternativen zu Mikro-Frontends. Dies sind alles gültige Ansätze, und jeder von ihnen hat Vor- und Nachteile.

Monolithen

Eine kleine Anwendung, die nicht häufig geändert werden muss, kann sehr schnell als Monolith bereitgestellt werden. Selbst in Situationen, in denen ein erhebliches Wachstum erwartet wird, ist ein Monolith ein natürlicher erster Schritt. Später kann der Monolith entweder ausgemustert oder zu einer flexibleren Struktur umgebaut werden. Wenn Sie mit einem Monolithen beginnen, kann Ihr Unternehmen schneller auf den Markt gehen, Kundenfeedback einholen und das Produkt schneller verbessern.

Monolithische Anwendungen neigen jedoch dazu, sich zu verschlechtern, wenn sie nicht sorgfältig gewartet werden oder wenn die Codebasis im Laufe der Zeit an Größe zunimmt. Wenn mehrere Teams wesentlich zu derselben Codebasis beitragen, tragen sie selten alle zu deren Wartung und Betrieb bei. Dies führt zu einem Ungleichgewicht der Zuständigkeiten, was sich auf die Geschwindigkeit auswirkt und zu Ineffizienzen führt. Gleichzeitig führt eine unbeabsichtigte Kopplung zwischen den Modulen eines Monolithen zu unbeabsichtigten Nebenwirkungen, wenn sich die Codebasis weiterentwickelt. Diese Nebenwirkungen können zu Fehlfunktionen und Ausfällen führen.

N-Tier-Anwendungen

Eine komplexere Anwendung mit einem relativ statischen Entwicklungstempo kann als dreistufige Architektur (Präsentation, Anwendung, Daten) mit einer REST- oder GraphQL-Schicht zwischen Frontend und Backend erstellt werden. Dies ist viel flexibler, und Teams für die verschiedenen Stufen können sich bis zu einem gewissen Grad unabhängig voneinander entwickeln. Der Nachteil einer n-Tier-Anwendung besteht darin, dass es viel schwieriger ist, Funktionen bereitzustellen. Frontend und Backend sind durch einen API-Vertrag entkoppelt, sodass grundlegende Änderungen zusammen implementiert werden müssen oder die API versioniert werden muss.

Stellen Sie sich das folgende gängige Szenario vor: Wenn die Veröffentlichung einer neuen Funktion eine Änderung des Datenschemas erfordert, kann es Tage dauern, bis sich die Produktbesitzer mit einem Frontend-Team auf eine Reihe von Funktionen geeinigt haben. Dann wird das Frontend-Team das Backend-Team bitten, die Funktionalität seinerseits zu entwickeln und zu veröffentlichen. Das Backend-Team wird mit den Datenbesitzern zusammenarbeiten, um ein Datenbankschema-Update zu veröffentlichen. Als Nächstes wird das Backend-Team eine neue Version der API veröffentlichen, damit das Frontend-Team seine Änderungen entwickeln und veröffentlichen kann. In diesem Szenario kann die Übertragung aller Änderungen an der Produktion Wochen oder sogar Monate dauern, da jedes Team seinen eigenen Backlog, seine eigenen Prioritäten und Mechanismen für die Entwicklung, das Testen und die Veröffentlichung von Änderungen hat.

Microservices

In einer Microservices-Architektur ist das Backend in kleine Dienste unterteilt, von denen jeder ein bestimmtes Geschäftsproblem innerhalb eines begrenzten Kontextes adressiert. Jeder Microservice ist zudem stark von anderen Diensten abgekoppelt, da er über einen klar definierten Schnittstellenvertrag verfügt.

Es ist erwähnenswert, dass begrenzte Kontexte und Schnittstellenverträge auch in gut gestalteten Monolithen und n-Tier-Architekturen existieren sollten. In einer Microservices-Architektur erfolgt die Kommunikation jedoch über das Netzwerk, normalerweise über das HTTP-Protokoll, und Dienste verfügen über eine eigene Laufzeitinfrastruktur. Dies unterstützt die unabhängige Entwicklung, Bereitstellung und den Betrieb der einzelnen Back-End-Dienste.

Wählen Sie den Ansatz für Ihre Anforderungen

Monolithen und n-Tier-Architekturen bündeln Probleme mehrerer Domänen in einem technischen Artefakt. Dadurch lassen sich Aspekte wie Abhängigkeiten und interner Datenfluss leicht verwalten, aber die Bereitstellung neuer Funktionen wird dadurch erschwert. Um eine kohärente Codebasis aufrechtzuerhalten, investiert ein Team aufgrund der großen Codebasis, mit der es umgehen muss, oft Zeit in Refactoring und Entkopplung.

Anwendungen, die von wenigen Teams entwickelt wurden, benötigen möglicherweise nicht die zusätzliche Komplexität, die mit der Umstellung auf Mikro-Frontends einhergeht. Dies gilt insbesondere dann, wenn die Teams nicht die Strafen zahlen müssen, die sich aus einer hohen Kopplung und langen Vorlaufzeiten für die Veröffentlichung von Änderungen ergeben.

Zusammenfassend lässt sich sagen, dass komplexere und verteilte Architekturen oft die richtige Wahl für komplexe und schnelllebige Anwendungen sind. Für kleine bis mittelgroße Anwendungen ist eine verteilte Architektur einer monolithischen Architektur nicht unbedingt überlegen, insbesondere wenn sich die Anwendung innerhalb kurzer Zeit nicht dramatisch weiterentwickelt.