Wie man gemeinsame Frontend-Komponenten auf Microservices verwaltet

Question

Wie verwaltet Frontend auf Microservices, vor allem, wenn Sie gemeinsame Komponenten haben? Ich habe ein paar Lösungen im Internet gefunden, aber alle haben einige Nachteile und keiner von ihnen passt gut zu uns.

Lassen Sie mich mein Problem klären. Wir haben mehr als 5 Gruppen von Menschen, die an verschiedenen Microservices in einem großen Einzelprojekt arbeiten. Und fast alle von ihnen haben einige gemeinsame, gemeinsame Komponenten am Frontend. Und diese Komponenten sind riesig, da sie bereits ein anderes Projekt sind, aber vollständig geteilt werden. Wie verwalten Sie diese freigegebenen Komponenten oder sollten wir sie duplizieren?

Die erste Lösung, die ich gefunden habe, ist es, diese Komponenten von einem einzigen Punkt wie node packages und npm install zu teilen und zu warten, wenn sie von verschiedenen Gruppen benötigt werden. Aber an diesem Punkt ist der Microservice-Ansatz gebrochen, da jeder von diesen Komponenten abhängig sein wird und niemand in der Lage sein wird, so schnell zu warten, wie sie brauchen, nicht gut. Und sehr schwer zu pflegen, da in Zukunft verschiedene Gruppen unterschiedliche Bedürfnisse von der Komponente haben können.

Zweitens ist es, die Komponenten nach jedem Projekt zu duplizieren und innerhalb der Microservice-Gruppe zu entwickeln, aber dieses Mal wird es sehr frankenstein und die allgemeinen Konzepte, die wir befolgen sollten, sind schwer zu fangen. Es ist ein echtes Enterprise-Projekt, bei dem alle Komponenten in Bezug auf das Verhalten übereinstimmen und auf die anderen Komponenten im Projekt achten sollten.

Also brauchen wir eine Frontend-Lösung für Microservices, die für ein Enterprise-Projekt geeignet sein soll, das die gleichen Regeln (wie Schriftgröße, Farbe, Aktionen etc.) an verschiedenen Stellen beachten muss, da es monolithisch geschrieben, aber wartbar ist von verschiedenen Gruppen gleichzeitig.

Wie können wir das ausgleichen oder können wir?

Dank @kayess: Wie kann man den Shared Kernel auf Microservices anwenden, da die Teams nicht voneinander abhängig sind?

Answer 1

Erste Lösung, die ich gefunden ist, diese Komponenten gemeinsam zu machen und von einem einzigen Punkt wie Knoten Pakete zu erhalten und npm installieren, wenn aus verschiedenen Gruppen benötigt. Aber an diesem Punkt der Micro Ansatz ist gebrochen, da jeder dieser Komponenten abhängig sein wird

Ich glaube, Ihr Verständnis von einem Micro falsch ist. Fowlers Definition eines Micro:

Kurz gesagt, die Micro Baustil 1 ist ein Ansatz zur eine einzelne Anwendung als eine Suite von kleinen Dienstleistungen zu entwickeln, die jeweils in einem eigenen Prozess ausgeführt wird und mit leichten Mechanismen in Verbindung steht, oft eine HTTP-Ressourcen-API.

Es ist in Ordnung für Microservices in Ihrem Unternehmen, gemeinsame Komponenten zu haben. Microservices sind viel höhere Abstraktionsebene als eine Komponente. Versuchen Sie nicht, jede Komponente zu einem Microservice zu machen.

Sie sollten Ihre Komponenten jeweils in einem separaten Repository verwalten. Verwenden Sie semantic versioning, um Updates zu veröffentlichen und Kompatibilitätspausen zu überwachen.

Und sehr schwer zu pflegen, da in der Zukunft verschiedene Gruppen unterschiedliche Bedürfnisse von der Komponente.

Ich glaube nicht, dass dies schwer zu pflegen ist. Die Wartbarkeit Ihrer Konfiguration ist sicherlich nicht höher als die jedes Framework, da Millionen von Programmierern von diesen Frameworks abhängig sind und diese gemeinsam entwickeln. Es ist eine Frage der Fähigkeit des Betreuers.

Sie mit einem monolithischen Repository Ansatz gehen können (setzen alle Komponenten in eine einzige, aber eigenständige Repo), aber ich denke, das wird mess up Dinge ziemlich schnell.

Answer 2

Wir standen vor dem gleichen Problem, aber nicht nur mit Front-End-Komponenten.

So bauten wir ein einfaches Komponenten-Management-System namens "Bit". Wir veröffentlichten es zu GitHub:

https://github.com/teambit/bit

Es ermöglicht Sie, diese Komponenten aus dem Code leicht zu extrahieren und sie alle an einem Ort mit Versionierung, CI und allem verwalten. Es ermöglicht den Mitarbeitern in anderen Teams, Komponenten einfach von demselben Ort aus zu exportieren und zu importieren und sie für Repos, Anwendungen und Microservices zu verwenden.

Sie sind willkommen, um es auszuprobieren. Sie können sich auch frei mit dem Bit community hub verbinden, um Ihre Open-Source-Komponenten zu hosten oder mit Ihrem Team/der Community zu finden und zu teilen. Hier ist ein Beispiel für eine wiederverwendbare Komponente mit einer MIT-Lizenz und zwei bestandenen Tests mit der Bezeichnung array/diff.

Viel Glück!