マイクロサービスベースの環境で「フロントエンド」をどうするか
私たちは最近、モノリシックWebアプリをマイクロサービスに分割し始め、ゆっくりと機能をスライスして個別のマイクロサービスに書き直しました。フロントエンドの作業を整理する最良の方法がわからない場合を除いて、すべて順調に進んでいます。製品チームに分かれ、少数のマイクロサービスのコードをそれぞれが管理して、機能領域を提供しています。検索、CMS、チェックアウトなど。各チームにはプロダクトオーナー、技術リーダー、スクラムマスターがいます。
問題は、これらの製品チームのそれぞれが独自のバックエンドコードベースを持っている一方で、フロントエンド開発者が各製品チームに座っている単一のフロントエンドReact.jsコードベースがあることです。これは多くの問題を引き起こしています：
- フロントエンド開発者間の製品チーム間のコミュニケーションの欠如
- 他のチームの新機能をサポートするために他のチームが「所有」しているフロントエンドコードに変更を加える際の問題
- フロントエンドチームを代表する単一の技術エキスパートはいないが、他の製品チームには技術的なリードがあり、フロントエンドに対してこの役割を果たしている人はいない
私たちは他の人がこれをどのように扱っているのか疑問に思い、フロントエンドコードベースの分割、ビジネスユーザーが新機能のために通常従事するフロントエンド製品チームの作成、データ/サービスのリクエストなど、フロントエンドチームの他の製品チームが両方とも独自の問題のセットを持っているようです！
フロントエンドはある意味で最も重要な部分（ユーザーが実際に使用する部分）であり、独自のデータ構造、インフラストラクチャ、専門の開発者がいて、他のすべてのチームと通信する必要があります。バックエンドの残りの部分がサービスに分割されている場合、それも最も中心的な部分です。
したがって、動作する唯一の方法はフロントエンドに独自のチームを持たせるです。バックエンドを複数のチームに分割する前に言っておきますが、それはすでに行われています。
通信の欠如-バックエンドチームがフロントエンドで何かを行う唯一の方法は、フロントエンドチームと通信することです。
フロントエンドコードに加えられた変更を取得する際の問題-フロントエンドの製品所有者が、フロントエンドに最初に必要な機能を決定します。
フロントエンドのテクニカルリードがあります。
これも明らかです。フロントエンドとバックエンドを明確に分割することの利点の1つは、バックエンドをさらにビットに分割し始めることができないため、すでに整理されていると想定しているためです。バックエンドサービスでさまざまなことを行う完全に異なるフロントエンドをいくつか持つことができます。明らかにそれらは異なる製品になるでしょう。