技術共有

マイクロフロントエンド: Qiankun、Wojie、シングルスパ、iframe の比較

2024-07-12

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

1. マイクロフロントエンドフレームワークの概要

マイクロ フロントエンド フレームワークは、大規模なフロントエンド アプリケーションを複数の小規模で独立した保守可能なマイクロ フロントエンド アプリケーションに分割するように設計された技術ソリューションであり、各マイクロ フロントエンド アプリケーションは開発、テスト、展開、実行できます。全体的なコラボレーションとユーザー エクスペリエンスを維持しながら、独立して実行できます。このアーキテクチャはマイクロサービス アーキテクチャに似ていますが、フロントエンド領域に焦点を当てています。

2. 一般的なマイクロフロントエンドフレームワーク

  1. 銭君 : シングル SPA に基づいて Ant Financial によって開発および保守され、テクノロジー スタックに依存しないシンプルなアクセス機能を提供します。 Vue や React などの複数のフロントエンド フレームワークをサポートしており、変換コストが低く、使いやすい開発エクスペリエンスを備えています。
  2. シングルスパ : これは、シングル ページ アプリケーション (SPA) のルーティング管理に焦点を当てた、軽量の JavaScript フロントエンド ルーティング フレームワークです。それ自体は完全なマイクロ フロントエンド フレームワークではありませんが、多くのマイクロ フロントエンド実装の基礎となっています。
  3. インラインフレーム: iframe 自体はマイクロ フロントエンド フレームワークではありませんが、マイクロ フロントエンドの単純な実装としてよく使用されます。
  4. 無制限 : Unbounded マイクロ フロントエンド フレームワークは、Web コンポーネント + iframe をベースとしたマイクロ フロントエンド ソリューションで、低コスト、高速、ネイティブ分離、強力な機能などの一連の利点があります。以下は、無制限のマイクロ フロントエンド フレームワークの詳細な紹介です。

共通点:ルートが切り替わったときに、対応するアプリケーションのコードをロードしてコンテナ内で実行させることができます。

  • 持っているサブアプリケーションをロードおよびアンロードする機能、ページがあるサブアプリケーションから別のサブアプリケーションに切り替わるとき、通常どおりにロードしてレンダリングできます。
  • 持っているルーティング状態保持機能、サブアプリケーションをアクティブ化した後、ブラウザの更新、サブアプリケーションの順方向および逆方向のルーティングは正常に動作します。
  • メインアプリとサブアプリ間、サブアプリとサブアプリ間お互いに通信できる
  • それぞれのマイクロアプリケーション独立した倉庫管理、独立した技術スタック開発、独立した導入、独立した運営

3. マイクロフロントエンドフレームワークの比較

特性千坤無制限シングルスパインラインフレーム
テクノロジースタックのサポートテクノロジースタックに依存せず、React、Vue、Angular などをサポートします。WebComponent に基づいて、複数のテクノロジー スタックをサポートテクノロジースタックに依存せず、複数のフロントエンドフレームワークをサポートテクノロジースタックは関係ありませんが、統合では互換性を考慮する必要があります
アクセス方法シンプル、JS API経由でアクセス比較的シンプルで、WebComponent を通じてカプセル化されています。複雑、単一スパのライフサイクルを構成する必要があるシンプル、HTMLタグ経由で埋め込み
サンドボックスの分離JSサンドボックスとスタイル分離を提供します自然な分離のために WebComponent を使用する開発者はサンドボックス分離を自分で実装する必要があるiframe 自然分離
ルート管理ルーティングステータスのメンテナンスと設定可能なルーティングマッピングをサポート仮想ルーティングをサポートし、ルーティング ステータスを維持しますトップレベルのルートとして、サブアプリケーションのルートを自分で管理する必要があります。ルーティングは iframe 自体内のアプリケーションによって管理されます
アプリケーション通信親子アプリケーション間および親子アプリケーション間の通信メカニズムを提供する通信をサポートするコンポーネントベースのAPIを提供開発者は通信メカニズムを自分で実装する必要があるpostMessage や URL パラメーターなどを介して通信できます。
リソースのプリロード静的リソースのプリロードをサポート静的リソースのプリロードをサポートアプリケーションの遅延読み込みをサポートするプリロード、オンデマンドのロードはサポートされていません
パフォーマンスへの影響低く、サンドボックスと遅延読み込みを通じて最適化されています低いですが、WebComponent にはパフォーマンスのオーバーヘッドがある可能性があります低いですが、アプリケーションの最適化に依存します高くすると、iframe の読み込みとレンダリングのオーバーヘッドが大きくなります
開発経験さらに、豊富な API とドキュメントを提供しますコンポーネントベースの API がより直感的に改善されました一般に、多くの詳細を自分で処理する必要があります既存のアプリケーションに簡単に統合できるようになりました
生産の可用性実証済みで実稼働環境に適しています実稼働環境に適していますが、コミュニティのサポートが少ない場合があります本番環境に適しているが、開発者自身による改善が必要実稼働環境に適していますが、セキュリティとパフォーマンスの問題には慎重に対処する必要があります
適応コストより高い場合は、ルーティング、ライフサイクルなどを調整する必要があります。中程度、主に WebComponent に適応より高い、単一スパのアーキテクチャについての深い理解が必要低いですが、互換性とパフォーマンスの問題に注意する必要があります

マイクロ フロントエンド フレームワークは、テクノロジー スタックの独立性、独立した開発と展開、増分アップグレードなど、フロントエンド アプリケーションの開発に多くの利点をもたらします。ただし、アクセスの難易度が高いことやリソース共有機能が不十分であることなど、いくつかの欠点もあります。したがって、マイクロフロントエンド フレームワークを使用するかどうかを選択する場合は、プロジェクト固有のニーズとチームの技術力に基づいて総合的に検討する必要があります。同時に、実際のアプリケーションにおいては、プロジェクトの円滑な進行とシステムの安定稼働を確保するために、マイクロフロントエンドフレームワークの選択、アーキテクチャ設計、コード管理などの課題にも注意を払う必要があります。システム。