Was tun mit dem „Frontend“ in einer auf Microservices basierenden Umgebung?

Wir haben vor kurzem begonnen, unsere monolithische Web-App in Microservices aufzuteilen, die Funktionalität langsam abzuschneiden und in einzelne Microservices umzuschreiben. Alles läuft gut, außer wir sind uns nicht sicher, wie wir die Frontend-Arbeit am besten organisieren können. Wir haben uns in Produktteams aufgeteilt, wobei jeder den Code für eine kleine Anzahl von Mikrodiensten verwaltet, um einen Funktionsbereich bereitzustellen, z. B. Suche, CMS, Kasse usw., wobei jedes Team einen Produktbesitzer, einen technischen Leiter und einen Scrum-Master hat.

Das Problem ist, dass jedes dieser Produktteams zwar eine eigene Backend-Codebasis hat, wir jedoch eine einzige Frontend-Codebasis von React.js mit Frontend-Entwicklern in jedem Produktteam haben. Dies verursacht eine Reihe von Problemen:

• Fehlende Kommunikation zwischen produktübergreifenden Teams zwischen Frontend-Entwicklern
• Probleme beim Ändern des Frontend-Codes, den das andere Team "besitzt", um neue Funktionen anderer Teams zu unterstützen
• Kein einziger technischer Experte, der das Frontend-Team vertritt, während andere Produktteams technische Leads haben, gibt es niemanden, der diese Rolle für das Frontend erfüllt

Wir haben uns gefragt, wie andere Leute damit umgehen, und haben einige Ansätze erörtert, z. B. die Aufteilung der Frontend-Codebasis, die Schaffung eines Frontend-Produktteams, mit dem sich die Geschäftsbenutzer normalerweise für neue Funktionen und Anfragen nach Daten / Diensten beschäftigen andere Produktteams aus dem Frontend-Team, aber beide scheinen ihre eigenen Probleme zu haben!

Das Frontend ist in gewisser Hinsicht der wichtigste Teil (es ist der Teil, den die Benutzer tatsächlich verwenden), es verfügt über eigene Datenstrukturen, Infrastruktur, spezialisierte Entwickler und muss mit allen anderen Teams kommunizieren. Wenn der Rest des Backends in Services aufgeteilt ist, ist dies auch der zentralste Teil.

Die einzige Möglichkeit zu arbeiten besteht darin , das Frontend über ein eigenes Team zu verfügen , bevor Sie das Backend in mehrere Teams aufteilen. Dies ist jedoch bereits geschehen.

Mangelnde Kommunikation - Die einzige Möglichkeit für ein Backend-Team, etwas im Frontend zu tun, besteht in der Kommunikation mit dem Frontend-Team.

Probleme beim Ändern des Frontend-Codes - Der Product Owner des Frontends entscheidet, welche Funktionen zuerst in das Frontend integriert werden müssen, sonst niemand.

Es gibt einen technischen Vorsprung für das Frontend.

Dies ist auch offensichtlich, weil einer der Vorteile einer klaren Aufteilung zwischen Frontend und Backend (ohne die Sie das Backend nicht in weitere Teile aufteilen können, also gehe ich davon aus, dass Sie das bereits erledigt haben) darin besteht, dass Sie es sind könnte mehrere völlig unterschiedliche Frontends haben, die unterschiedliche Dinge mit den Backend-Diensten tun. Das wären natürlich unterschiedliche Produkte.