マイクロフロントエンドを理解する

皆さん、マイクロ フロントエンドについて少し話しましょう。このトピックに対する実践的で直接的なアプローチを Web 上で探しましたが、関連する資料がほとんど見つからなかったため、使用の主な理由、実装上の課題、大企業で使用されているこのアーキテクチャがどのように機能するかを共有するためにこのテーマを取り上げることにしました。初心者向けの簡素化されたアプローチ。
この件に関する詳細情報にアクセスするには、Cam Jackson によるこの記事を参照することをお勧めします https://martinfowler.com/articles/micro-frontends.html

要点をまっすぐに

マイクロ フロントエンドは、フロントエンド Web アプリケーションが独立して配信され、親アプリケーション内で構成されるアーキテクチャ スタイルです。
このアーキテクチャを採用する主な利点は次のとおりです。

• より小さく、より一貫性があり、保守しやすいコードベース
• 自律的で分離されたチーム;
• 拡張性の向上;
• リファクタリング能力の向上;

実際に、ユーザーが複数の異なるドメインから異なる機能にアクセスできる Web アプリケーションを想像してみましょう。このアプリケーションは単一のチームによって開発されており、新しい機能が登場するたびに、このチームはパイプラインにコード ベースを 1 つだけ持ちながら、コーディング、構築、テスト、デプロイに取り組む必要があります。

プロジェクトが拡張され、さまざまなドメインから新しい機能を獲得するシナリオを想像すると、コードの複雑さと機能配信の効率の増加により、開発プロセスでいくつかの競合が発生するのは当然です。

とはいえ、マイクロ フロントエンドを独立して展開することが不可欠です。これにより、展開の範囲が縮小され、関連するリスクも軽減されます。フロントエンド コードがホストされる方法や場所に関係なく、各マイクロ フロントエンドには、運用環境に至るまでビルド、テスト、デプロイを行う独自の継続的デリバリー パイプラインが必要です。責任あるチームは、他のコードベースやパイプラインの現在の状態をほとんど考慮せずに各マイクロ フロントエンドをデプロイできなければなりません。

さらに以下では、コンテナと呼ばれる親アプリケーションにさまざまな分離された機能をデプロイする独立したチームによる継続的な分離配信のフローを観察できます。

結論

マイクロ フロントエンドは、大規模なアプリケーションをより小さく、より管理しやすいチャンクにスライスし、それらの間の依存関係を明示することを目的としています。私たちのテクノロジーの選択、コードベース、チーム、リリースプロセスは、過剰な調整を行うことなく、互いに独立して運用および進化できなければなりません。

間もなく、実際にマイクロ フロントエンドを実装するためのチュートリアルを提供する予定です。企業環境における実際の事例をいくつか紹介します。

以上がマイクロフロントエンドを理解するの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。