マイクロサービスベースの環境で「フロントエンド」をどのように処理しますか？

私たちは最近、モノリシックWebアプリをマイクロサービスに分割し始め、ゆっくりと機能をスライスして個別のマイクロサービスに書き直しました。フロントエンドの作業を整理する最善の方法がわからない場合を除いて、すべて順調に進んでいます。私たちは製品チームに分かれて、少数のマイクロサービスのコードをそれぞれ管理し、検索、CMS、チェックアウトなどの機能領域を提供します。各チームには製品所有者、技術リーダー、スクラムマスターがいます。

問題は、これらの製品チームがそれぞれ独自のバックエンドコードベースを持っている一方で、フロントエンド開発者が各製品チームに座っている単一のフロントエンドReact.jsコードベースがあることです。これは多くの問題を引き起こしています：

• フロントエンド開発者間の製品チーム間のコミュニケーションの欠如
• 他のチームの新機能をサポートするために他のチームが「所有」しているフロントエンドコードに変更を加える際の問題
• フロントエンドチームを代表する単一の技術エキスパートは存在しませんが、他の製品チームには技術的なリードがあり、フロントエンドでこの役割を果たしている人はいません。

私たちは他の人がこれをどのように扱っているのか疑問に思い、フロントエンドコードベースの分割、ビジネスユーザーが新機能のために通常従事するフロントエンド製品チームの作成、データ/サービスのリクエストなど、フロントエンドチームの他の製品チームですが、どちらにも独自の問題があります。

フロントエンドはある意味で最も重要な部分（ユーザーが実際に使用する部分）であり、独自のデータ構造、インフラストラクチャ、専門の開発者がいて、他のすべてのチームと通信する必要があります。バックエンドの残りの部分がサービスに分割されている場合、それも最も中心的な部分です。

そのため、動作する唯一の方法は、フロントエンドに独自のチームを持たせることです。バックエンドを複数のチームに分割する前に言いますが、それはすでに行われています。

通信の欠如-バックエンドチームがフロントエンドで何かを行う唯一の方法は、フロントエンドチームと通信することです。

フロントエンドコードに加えられた変更を取得する際の問題-フロントエンドの製品所有者が、フロントエンドに最初に必要な機能を決定します。

フロントエンドのテクニカルリードがあります。

これも明らかです。フロントエンドとバックエンドを明確に分割することの利点の1つは、バックエンドをさらにビットに分割し始めることができないため、すでに整理されていると想定しているためです。バックエンドサービスで異なる処理を行う完全に異なるフロントエンドをいくつか持つことができます。明らかにそれらは異なる製品になるでしょう。