Meine Erfahrung mit Micro-Frontends

Micro-Frontends erfreuen sich immer größerer Beliebtheit, und das aus sehr guten Gründen. Wenn Sie nicht wissen, was Micro-Frontends sind, empfehle ich Ihnen, diesen Artikel zu lesen.

Ich arbeite seit fast 2 Jahren mit Micro-Frontends und liebe es, mit ihnen zu arbeiten. Der größte Vorteil meiner Meinung nach ist, dass sie den Besitz erhöhen. Die meisten Micro-Frontends sind nach den Domänen einer Anwendung aufgeteilt, wobei ein Team für eine bestimmte Domäne der Website verantwortlich ist (z. B. Teamprodukte, Teamkonto, Team-Checkout usw.). Es erhöht das Domänenwissen im Team, das Wissen über die Codebasis und beschleunigt den Bereitstellungsprozess. Ein großer Nachteil ist jedoch, dass es noch keine Erfahrungen gibt. Dafür möchte ich meine Gedanken, Erfahrungen und Entscheidungen teilen.

Entscheide dich nicht für Technologie-Agnostiker, denn das Internet sagt es aus

Technologieagnostiker sind ein häufiger Vorteil, den Sie beim Lesen von Micro-Frontends feststellen werden. Beachten Sie, dass dies auch große Nachteile hat. Ich würde sagen, dass diese Entscheidung auf der Art der Anwendung basieren sollte, die Sie erstellen. In unserem Fall haben wir eine E-Commerce-Plattform aufgebaut. Dies bedeutet, dass unsere Anwendung viele gemeinsam genutzte Komponenten enthält (z. B. kann ein Produkt in einer beliebigen Domain angezeigt werden). Aus diesem Grund möchten wir nicht technologieunabhängig sein. Dadurch konnten wir eine gemeinsam genutzte Webkomponentenbibliothek erstellen, die von jedem verwendet werden kann. Heutzutage gewinnen native Webkomponenten mehr an Bedeutung, sodass dieses Argument in Kürze ungültig werden könnte.

Ein weiterer Vorteil, den wir als Technologieunabhängige nicht hatten, ist die Möglichkeit, eine „App-Shell“ zu erstellen. Die App-Shell ist eine kleine Bibliothek, die jedes Team zum Booten seiner Anwendung verwendet. Es enthält den Header, die Fußzeile, die Authentifizierung, das serverseitige Rendern und einige andere Funktionen. Wenn sich an einer dieser Funktionen etwas ändert, muss jedes Team lediglich sein NPM-Modul aktualisieren, um die Änderungen zu implementieren.

Technologieagnostiker können auf jeden Fall funktionieren, wenn Ihre Domains nicht viel Erfahrung mit der Benutzeroberfläche oder dem Status haben müssen. In diesem Fall würde ich empfehlen, mehr Code freizugeben und nicht technologieunabhängig zu sein. Andernfalls kann die Entwicklung einer konsistenten Benutzeroberfläche zu einer großen Herausforderung werden, oder Ihre Wartungskosten (jedes Team, das die gleichen Änderungen durchführt) können sich dramatisch erhöhen, wenn Ihre Anwendung größer wird.

Bildergebnis für das Backend für das Frontend
https://medium.com/tech-tajawal/backend-for-frontend-using-graphql-under-microservices-5b63bbfcd7d9

Benutze ein BFF (Backend für Frontend)

Wenn Sie mit dem Konzept des Backends für das Frontend nicht vertraut sind, empfehle ich Ihnen, es hier nachzulesen.

Backend für Frontends sind ein wesentliches Konzept in einer Micro-Fronted-Umgebung. Sie können damit Microservices zusammenfügen und benutzerdefinierte APIs nur für Ihre Anwendung erstellen, die Authentifizierung verwalten und vieles mehr.

Es gibt verschiedene Ansätze für BFFs. Sie können eine BFF für alle Ihre Mikro-Frontends haben, was der gängigste Ansatz ist. Wir entscheiden uns für ein BFF pro Micro-Frontend. Dadurch konnten wir dem Team mehr Flexibilität bieten. Das Account-Domain-Team verfügt beispielsweise über eine eigene Account-BFF. Sie müssen sich nie darum kümmern, Änderungen vorzunehmen, wenn Sie das API-Design einer kontobezogenen Funktion ändern, da sie der einzige Konsument ihrer BFF / API sind.

Nahtschicht

Sobald Sie verschiedene Micro-Frontends haben, müssen Sie diese zusammenfügen. Viele Online-Ressourcen sprechen von einer Heftanwendung. Dies ist eine Umbrella-Anwendung, die die aktuelle Route überprüft und das entsprechende Micro-Frontend abruft.

In unserem Fall wollten wir keine Stitching-Anwendung, es ist unnötiger Overhead, und Sie sind sich nie zu 100% sicher, dass der Stitching-Server gemäß Design in Kombination mit Ihrem Micro-Frontend funktioniert. Darüber hinaus wollten wir mehr Freiheit für unsere Mikro-Frontends, und wir entscheiden uns, dass die Mikro-Frontends für das Rendern einer eingehenden Anfrage ohne Heftebene verantwortlich sein sollen.

Kubernetes zur Rettung

Kubernetes ist ein Open-Source-Container-Orchestrierungssystem zur Automatisierung der Anwendungsbereitstellung, -skalierung und -verwaltung. Darüber hinaus werden Eingangsregeln für das Routing verwendet. Dies ist alles, was wir für die Orchestrierung unserer Micro-Frontends benötigen. Möchten Sie den Benutzer auf eine andere Seite in Ihrem Micro-Frontend umleiten? Verwenden Sie einen internen Push. Möchten Sie den Benutzer zu einem anderen Microfrontend umleiten? Benutze einfach eine href und Kubernetes kümmert sich um das Routing. Darüber hinaus sichert kubernetes unsere DevOps-Arbeitsweise und macht die Teams von Ende zu Ende für ihre Anwendung verantwortlich.

Die Protokollierung wird sehr wichtig sein

Sie führen jetzt eine Micro-Frontend-Architektur für die Produktion aus. Es gibt ein Problem, bei dem Benutzer nicht immer von einem bestimmten Mikroserver aus auf die richtigen Daten zugreifen können. Viel Glück beim Debuggen! Das Debuggen mit Micro-Frontends wird schwierig. Oft ist nicht ganz klar, welches Micro-Frontend (oder welche Dienste) unerwünschtes Verhalten verursachen kann. Es kann sich sogar um eine Kombination verschiedener Micro-Frontends handeln. Stellen Sie sicher, dass die Protokollierung korrekt implementiert ist. Sie werden sich später bedanken, wenn zufällige Probleme auftauchen. Protokollieren Sie immer die korrekten Fehlercodes von Mikroservern, geben Sie eine eindeutige Meldung an, welches Problem auftritt, und stellen Sie sicher, dass Sie eine Korrelations-ID verwenden, um eine einzelne Anforderung zu verfolgen. Werkzeuge wie Kibana sind ein Muss.

Teilen Sie Ihr Wissen zwischen den Teams

Jedes Team ist für seine eigene Lösung verantwortlich. Daher gibt es nicht oft einen Grund, ein anderes Team zu fragen, wie etwas implementiert werden soll. Das ist gefährlich! Öffnen Sie unbedingt Ihre Augen und schauen Sie sich um. Oft war bereits ein anderes Team mit diesem Problem konfrontiert, als es etwas entwickelte. Darüber hinaus ist es gut, die Funktionen zu kennen, an denen andere Teams arbeiten. Es geht nur darum, was der Benutzer erfährt, und das ist mehr als nur Ihre Domain. Überprüfen Sie den Code anderer Teams. Sitzen Sie einmal pro Woche / alle zwei Wochen mit allen Entwicklern zusammen. Teilen Sie die coolen Dinge, die Sie und Ihr Team bauen!

Stellen Sie so oft wie möglich in der Produktion bereit

Am wichtigsten ist, genießen und nutzen Sie die Arbeit mit Micro-Frontends :)! Sie können Funktionen völlig unabhängig von anderen Teams entwickeln und für die Produktion bereitstellen. Darüber hinaus ist Ihr Team für alle Funktionen in Ihrer Domain verantwortlich. Entwickeln Sie kleine Features und stellen Sie sie häufig bereit. Vergessen Sie nicht, die Auswirkungen der von Ihnen erstellten Features zu überwachen.