翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

マイクロフロントエンドと代替アーキテクチャの比較

すべてのアーキテクチャ戦略と同様に、マイクロフロントエンドを採用する決定は、組織の原則に基づく評価基準に基づいている必要があります。マイクロフロントエンドには利点と欠点があります。組織がマイクロフロントエンドを使用することを決定した場合、分散システムの課題に対処するための戦略を設定する必要があります。

アプリケーションアーキテクチャを選択する場合、マイクロフロントエンドの最も一般的な代替手段は、モノリス、n 層アプリケーション、マイクロサービスとシングルページアプリケーション (SPA) フロントエンドの組み合わせです。これらはすべて有効なアプローチであり、それぞれに利点と欠点があります。

モノリス

頻繁な変更を必要としない小さなアプリケーションは、モノリスとして非常に迅速に配信できます。大幅な成長が予想される状況でも、モノリスは自然な最初のステップです。その後、モノリスをリタイアするか、より柔軟な構造にリファクタリングできます。モノリスから始めることで、組織は市場に進出し、顧客のフィードバックを得て、製品を迅速に改善できます。

ただし、モノリシックアプリケーションは、慎重に保守されていない場合や、コードベースのサイズが時間の経過とともに大きくなると、低下する傾向があります。複数のチームが同じコードベースに大きく貢献する場合、すべてがメンテナンスと運用に寄与することはほとんどありません。これにより責任のバランスが崩れ、速度に影響し、非効率になります。同時に、モノリスのモジュールが誤って結合されると、コードベースが進化するにつれて意図しない副作用が発生します。これらの副作用により、誤動作や機能停止が発生する可能性があります。

N 層アプリケーション

比較的静的な進化ペースを持つより複雑なアプリケーションは、フロントエンドとバックエンドの間に REST または GraphQL レイヤーを持つ 3 層アーキテクチャ (表現、アプリケーション、データ) として構築できます。これははるかに柔軟であり、異なる階層のチームはある程度独立して開発できます。n 層アプリケーションの欠点は、機能のデプロイがはるかに難しいことです。フロントエンドとバックエンドは API 契約によって分離されるため、重大な変更を一緒にデプロイするか、API をバージョニングする必要があります。

次の一般的なシナリオを検討してください。新機能をリリースする際にデータスキーマの変更が必要な場合、製品所有者がフロントエンドチームと一連の機能について合意するまでに数日かかることがあります。次に、フロントエンドチームはバックエンドチームに、ユーザー側で機能の開発とリリースを依頼します。バックエンドチームは、データ所有者と協力してデータベーススキーマの更新をリリースします。次に、バックエンドチームは API の新しいバージョンをリリースし、フロントエンドチームが変更を開発してリリースできるようにします。このシナリオでは、各チームに変更の開発、テスト、リリースに関する独自のバックログ、優先順位、メカニズムがあるため、本番環境へのすべての変更の伝播に数週間または数か月かかる場合があります。

マイクロサービス

マイクロサービスアーキテクチャでは、バックエンドは小さなサービスに分解され、それぞれが制限付きコンテキスト内の特定のビジネス上の懸念に対処します。各マイクロサービスは、明確に定義されたインターフェイス契約を公開することで、他のサービスとの密接な分離も行われます。

境界コンテキストとインターフェイスコントラクトは、適切に作成されたモノリスと n 層アーキテクチャにも存在する必要があります。ただし、マイクロサービスアーキテクチャでは、通信はネットワーク、通常は HTTP プロトコルを介して行われ、サービスには専用のランタイムインフラストラクチャがあります。これにより、各バックエンドサービスの開発、配信、運用が個別にサポートされます。

要件に対するアプローチの選択

モノリスと n 層アーキテクチャは、複数のドメインの懸念を 1 つの技術アーティファクトにバンドルします。これにより、依存関係や内部データフローなどの側面の管理が容易になりますが、新しい機能の提供はより困難になります。一貫したコードベースを維持するために、チームは多くの場合、リファクタリングとデカップリングに時間を費やします。これは、処理する必要のあるコードベースが大きいためです。

一部のチームによって開発されたアプリケーションは、マイクロフロントエンドへの移行に伴う追加の複雑さを必要としない場合があります。これは、チームが高い結合とリリース変更への長いリードタイムのペナルティを支払っていない場合に特に当てはまります。

つまり、より複雑で分散型のアーキテクチャは、複雑で動きの速いアプリケーションに適しています。小規模から中規模のアプリケーションでは、特にアプリケーションが短期間で劇的に進化しない場合、分散アーキテクチャがモノリシックアーキテクチャよりも必ずしも優れているとは限りません。