JP7451825B2 - マイクロフロントエンドシステム、サブアプリケーションロード方法、電子機器、及びコンピュータープログラム製品 - Google Patents

Description

（関連出願への相互参照）
本出願は、出願番号が２０２０１１５２０１８４．６であり、出願日が２０２０年１２月２１日である中国特許出願に基づいて提出され、該中国特許出願の優先権を主張し、該中国特許出願の全ての内容が参照により本出願に組み込まれる。

本出願の実施例は、インターネットの技術分野に関し、マイクロフロントエンドシステム、サブアプリケーションロード方法、電子機器、コンピュータープログラム製品及びコンピューター可読記憶媒体に関するが、これらに限定されない。

フロントエンド開発の過程で、開発プロジェクトはますます大きくなり、しかも製品の機能は複雑であり、コードの衝突が頻繁であり、影響が巨大になる。この一連の問題に対して、マイクロフロントエンドが誕生した。マイクロフロントエンドは、バックエンドマイクロサービスの概念を参考にして、巨大なフロントエンドプロジェクトを一つ一つの小さなプロジェクトに分割し、これらの小さなプロジェクトは独立的に開発、実行する能力を完全に備える。システム全体は、これらの小さなプロジェクトの協働によって、全てのページの表示とインタラクションを実現する。

関連技術のマイクロフロントエンドフレームワークのルーティングサービスはＮｇｉｎｘサービスを使用して転送されるため、効率が低下し、センタールーティングはＮｇｉｎｘサービスの安定性に依存しており、ディザスタリカバリ処理方案は複雑であり、ＮｇｉｎｘサービスはＮｇｉｎｘサービスの構成に高度に依存しており、構成の変更はセンタールーティングＮｇｉｎｘサービスを再起動する必要があり、メンテナンスコストが高い。

本出願の実施例は、マイクロフロントエンドシステム、サブアプリケーションロード方法、電子機器、コンピュータープログラム製品及びコンピューター可読記憶媒体を提供し、独立的にメンテナンス・実行する可能なノード（Ｎｏｄｅ）サービスによって、容量拡張とディザスタリカバリ能力を向上させ、マルチフレームワークでのサブアプリケーション実行能力を提供する。

本出願の実施例の技術案は、以下のように実現される。

本出願の実施例は、マイクロフロントエンドシステムを提供し、前記マイクロフロントエンドシステムは、
ルーティング登録サービス、コマンドラインツール及びマイクロフロントエンド実行フレームワークを含み、
前記ルーティング登録サービスは、独立的にメンテナンス・実行（「保守・運用」、「メンテナンス・オペレーション」とも呼ばれる）するＮｏｄｅバックエンドサービスであり、メインアプリケーションのマイクロフロントエンド実行フレームワークに、サブアプリケーションのルーティング情報、前記サブアプリケーションのロード方式及び前記サブアプリケーションのデプロイメント情報を提供するように構成され、
前記コマンドラインツールは、コマンドラインによりサブアプリケーション新規作成機能、サブアプリケーションアクセス機能、サービス登録機能を提供するように構成され、
前記マイクロフロントエンド実行フレームワークは、前記メインアプリケーションで実行されるフレームワークであり、取得されたネットワーク要求に基づいて前記サブアプリケーションをロードして実行し、マルチフレームワークでのサブアプリケーション実行能力を提供するように構成される。

本出願の実施例は、サブアプリケーションロード方法を提供し、前記方法は、電子機器によって実行され、マイクロフロントエンドシステムのために構成され、前記マイクロフロントエンドシステムは、ルーティング登録サービス、サブアプリケーションロードモジュール及びサブアプリケーション実行モジュールを含み、前記方法は、
サブアプリケーションにアクセスするように構成されたネットワークアクセス要求を取得するステップであって、前記ネットワークアクセス要求に前記サブアプリケーションのユニフォームリソースロケータ（ＵＲＬ：Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）アドレスが含まれるステップと、
前記サブアプリケーションのＵＲＬアドレスに基づいて、前記ルーティング登録サービスから前記サブアプリケーションに対応するルーティング情報をプルするステップと、
前記ルーティング情報に基づいて、前記アクセス対象ページがサブアプリケーションのページであると決定した場合、前記サブアプリケーションロードモジュールは、前記ルーティング情報に基づいて前記ルーティング登録サービスから前記ルーティング情報に対応するサブアプリケーションリソースを取得するステップと、
前記サブアプリケーションリソースをロードする必要がある場合、前記サブアプリケーションロードモジュールは、前記サブアプリケーションリソースをロードするステップと、
前記サブアプリケーション実行モジュールは、前記サブアプリケーションリソースを実行し、サブアプリケーションのページをレンダリングするステップと、を含む。

本出願の実施例は、コンピューター可読記憶媒体を提供し、前記コンピューター可読記憶媒体は、実行可能な命令が記憶され、前記実行可能な命令は、プロセッサによって実行されるとき、上述のマイクロフロントエンドシステムに基づくサブアプリケーションロード方法を実現する。

本出願の実施例は、電子機器を提供し、前記電子機器は、メモリと、プロセッサとを含み、前記メモリはコンピュータープログラムを記憶し、前記プロセッサは、前記コンピュータープログラムにより、上述のマイクロフロントエンドシステムに基づくサブアプリケーションロード方法を実行する。

本出願の実施例は、コンピュータープログラム製品を提供し、前記コンピュータープログラム製品は、コンピュータープログラムを含み、前記コンピュータープログラムは、プロセッサによって実行されるとき、上述のマイクロフロントエンドシステムに基づくサブアプリケーションロード方法を実現する。

本出願の実施例は、以下の有益な効果を有する。

本出願の実施例によるマイクロフロントエンドシステムは、ルーティング登録サービス、コマンドラインツール及びマイクロフロントエンド実行フレームワークを含み、独立的にメンテナンス・実行するＮｏｄｅバックエンドサービスにより、優れた容量拡張とディザスタリカバリ能力を提供することができ、ルーティング登録サービスにより、メインアプリケーションのマイクロフロントエンド実行フレームワークにサブアプリケーションのルーティング情報、ロード方式及びサブアプリケーションのデプロイメント情報を提供し、コマンドラインツールにより、サブアプリケーション新規作成機能、サブアプリケーションアクセス機能、サービス登録機能を提供し、マルチフレームワークでのサブアプリケーション実行能力を提供する。

本出願の実施例によるマイクロフロントエンドシステムの構成の構造的模式図である。 本出願の実施例によるマイクロフロントエンドシステムの別の構成の構造的模式図である。 本出願の実施例によるマイクロフロントエンドシステムに基づくサブアプリケーションロード方法の実現フローの模式図である。 本出願の実施例によるマイクロフロントエンドシステムに基づくサブアプリケーションロード方法の別の実現フローの模式図である。 本出願の実施例によるマイクロフロントエンドシステムに基づくサブアプリケーションロード方法の実現フローの模式図である。 本出願の実施例によるマイクロフロントエンドシステムアーキテクチャの模式図である。 本出願の実施例によるマイクロフロントエンドシステムにおける通信メカニズムの模式図である 本出願の実施例によるサブアプリケーションロードモジュールによってサブアプリケーションリソースをロードする実現フローの模式図である。 本出願の実施例によるＪＳサンドボックスの設計模式図である。 本出願の実施例によるアプリケーション階層化の模式図である。

本出願の目的、技術案及び利点をより明確にするために、下記において図面を参照しながら本出願をさらに詳細に説明し、記載される実施例は、本出願に対する制限と見なすべきではない。当業者が創造的な労力を払うことなく得られる他の全ての実施例は、いずれも本出願の保護範囲に属する。

下記に記載される「いくつかの実施例」について、全ての可能な実施例のサブセットが記載されているが、理解可能なこととして、「いくつかの実施例」は全ての可能な実施例の同じサブセット又は異なるサブセットであってよく、しかも矛盾でなければ互いに組み合わせることができる。別途に定義されない限り、本出願の実施例で使用される全ての技術用語及び科学用語は、本出願の実施例の技術分野に属する当業者が一般に理解するものと同じ意味を有する。本出願の実施例で使用される用語は、本出願を限定することを意図するものではなく、単に本出願の実施例を説明するためのものである。

別途に定義しない限り、本明細書で使用される全ての技術用語及び科学用語は、本出願の技術分野に属する当業者が一般に理解するものと同じ意味を有する。本明細書で使用される用語は、本出願を限定することを意図するものではなく、単に本出願の実施例を説明するためのものである。

本出願の実施例をさらに詳細に説明する前に、本出願の実施例に係る名詞及び用語について説明する。本出願の実施例に係る名詞及び用語は、以下のように解釈される。

１）Ｖｕｅフレームワーク：ユーザインターフェースを構築するためのプログレッシブフロントエンドフレームワークであり、Ｖｕｅのコアライブラリはビューレイヤーのみに焦点を当てる。

２）Ｒｅａｃｔフレームワーク：ユーザインターフェースを構築するように構成されるＪａｖａＳｃｒｉｐｔ（ＪＳ）ライブラリであり、主にユーザインターフェースを構築するために構成され、Ｒｅａｃｔによって、さまざまなタイプのパラメータを渡すことができ、例えば、宣言コード、ユーザインターフェースのレンダリングが挙げられ、又は静的要素であってもよく、動的変数、ひいてはインタラクティブなアプリケーションコンポーネントを渡すこともできる。

３）ＪａｖａＳｃｒｉｐｔサンドボックスメカニズム：セキュリティメカニズムであり、実行中のプログラムに隔離環境を提供し、外部と隔離する実行環境を提供することによってＪＳコードを実行し、マイクロフロントエンドでは、独立的にオンラインで実行する、互いに干渉しないコード、デカップリングを支援し、メンテナンスコストを削減するためによく使用される。

４）ＷｅｂＷｏｒｋｅｒ：ハイパーテキストマークアップ言語（ＨＴＭＬ：Ｈｙｐｅｒ Ｔｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）５によって提供されるＪａｖａＳｃｒｉｐｔマルチスレッドソリューションであり、ユーザインターフェースの動作を停止させることなく、計算量の多いコードをＷｅｂＷｏｒｋｅｒに渡して実行することができる。それは他のスクリプトから独立しており、ページの性能には影響しない。

５）シャドウファイルオブジェクトモデル（ＳｈａｄｏｗＤｏｍ：Ｓｈａｄｏｗ Ｄｏｃｕｍｅｎｔ Ｏｂｊｅｃｔ Ｍｏｄｅｌ）：ハイパーテキストマークアップ言語の範疇に属し、ドキュメントのレンダリング時にドキュメントオブジェクトモデル要素サブツリーを挿入することが可能であり、ブラウザ開発者が独自のＨＴＭＬラベル、積層スタイルシート（ＣＳＳ：Ｃａｓｃａｄｉｎｇ Ｓｔｙｌｅ Ｓｈｅｅｔｓ）スタイル、特定のＪａｖａＳｃｒｉｐｔコードをパッケージングすることが可能であり、同時に開発者は＜ｉｎｐｕｔ＞、＜ｖｉｄｅｏ＞、＜ａｕｄｉｏ＞などのようなカスタマイズされた１レベルのラベルを作成することもできる。

６）Ｐｒｏｐｓ伝送：親コンポーネントのテンプレートは子コンポーネントを含み、親コンポーネントはデータ又はパラメータを子コンポーネントに一方向に伝送する必要があり、子コンポーネントはそれを受け取った後、パラメータに応じて異なるコンテンツをレンダリングするか、又は操作を実行し、この一方向にデータを伝送するプロセスはＰｒｏｐｓによって実現される。

７）カスタムイベント（Ｃｕｓｔｏｍ Ｅｖｅｎｔ）伝送：ＪａｖａＳｃｒｉｐｔとＨＴＭＬの間のインタラクションはイベントによって実現され、イベントはドキュメント又はブラウザウィンドウで発生するいくつかの特定のインタラクションの瞬間であり、ＪａｖａＳｃｒｉｐｔによって特定のカスタムイベントをいつでもトリガーすることができ、これらのイベントはブラウザが作成したイベントと同じである。

８）メッセージ送信ＰｏｓｔＭｅｓｓａｇｅ：ＨＴＭＬ５によって導入されたアプリケーションプログラムインターフェースのメソッドであり、異なるソースからのスクリプトが非同期方式で有効な通信を行うことをサポートし、テキストドキュメント間、マルチウィンドウのクロスドメインのメッセージ伝送を実現することができ、ウィンドウ間のデータ通信として構成されることが多く、これにより、それは、クロスドメイン通信の有効なソリューションにもなる。

９）Ｉｆｒａｍｅ：ハイパーテキストマークアップ言語のラベルであり、別のドキュメントを含むインラインフレーム（即ち行内フレーム）を作成するように構成される。

１０）Ｎｏｄｅ．ｊｓ：ＣｈｒｏｍｅＶ８エンジンに基づくＪａｖａＳｃｒｉｐｔの実行環境であり、イベント駆動、ノンブロッキングＩ／Ｏモデルを使用して、ＪａｖａＳｃｒｉｐｔをサーバの開発プラットフォームで実行させ、ＪａｖａＳｃｒｉｐｔをＰＨＰ、Ｐｙｔｈｏｎ、Ｐｅｒｌ、Ｒｕｂｙなどのサーバ言語と対等するスクリプト言語とさせる。

１１）Ｐｏｌｙｆｉｌｌｉｎｇ：あるメソッドがＪａｖａＳｃｒｉｐｔ仕様に既に存在するが、特定のＪａｖａＳｃｒｉｐｔエンジンはまだ該メソッドをサポートしていない場合、それを手動で実現することができ、それによってビルドインプロトタイプを補充する。

１２）Ｓｉｎｇｌｅ－ＳＰＡ：１セットのマイクロフロントエンドフレームワークであり、ブラウザによるアドレスの切り替えを引き継いでアプリケーションの切り替えの目的を達成し、各アプリケーションの起動から破棄までのライフサイクルも管理し、ライフサイクルの変化過程において、追加の機能（アニメーションなど）を加えることができるとともに、Ｓｉｎｇｌｅ－ＳＰＡは、既存のアプリケーションを統合するために、異なるＳＰＡフレームワークにプラグインも提供する。

１３）マイクロフロントエンド：メインアプリケーションとサブアプリケーションを含み、アプリケーションを複数の垂直部分のスライスに分割し、各スライスは下位階層のデータベースから上位階層のユーザインターフェースまで構築される。メインアプリケーションはフレームワークであり、主にログイン、メニュー、ナビゲーションを統合し、グローバルなデータとパブリックメソッドを提供し、それに対して、具体的な機能モジュールはできるだけサブアプリケーションで実現される。例えば、メインアプリケーションの機能は、ログイン、メニュー、及びナビゲーションを含むことができ、サブアプリケーションの機能は、具体的なページコンテンツに対応することができる。

１４）ウェブパック（ｗｅｂｐａｃｋ）：プロジェクト構造を分析し、ＪａｖａＳｃｒｉｐｔモジュール及びブラウザが直接実行できない拡張言語を見つけ、それらをブラウザ用に適切なフォーマットに変換してパッケージングするために使用される。図１０を参照して、図１０は、本出願の実施例によるアプリケーション階層化の模式図であり、以下に実際のバックグラウンド管理システムを例として説明し、バックグラウンド管理システムはログイン認証が必要であり、左側のメニューバーと上方の個人情報ナビゲーションバーがあり、中間部分は具体的なページコンテンツであり、この特徴に基づいて、バックグラウンド管理システムをメインアプリケーション（ログインモジュール＋メニューモジュール＋ナビゲーションモジュール）とサブアプリケーション（具体的なコンテンツページモジュール）の２つの部分に分けることができる。メインアプリケーションの位置づけはメインフレームワークであり、主にログインモジュール、メニューモジュール、ナビゲーションモジュールを統合し、グローバルなデータとパブリックメソッドを提供し、サブアプリケーションは独立性をさらに考慮する必要があり、マイクロフロントエンドの環境であれば、サブアプリケーションは全体的なアプリケーションの一部とするため、メインアプリケーションと密接な関係があるが、サブアプリケーション自体として相対的な独立性を有する必要もあり、メインアプリケーションから離れても独立的に実行することができ、サブアプリケーションは、メインアプリケーションに統合されてマイクロフロントエンドのアーキテクチャで実行することもでき、メインアプリケーションから離れて独立的に実行することもでき、例えば、メインアプリケーションはＷｅｂ検索アプリケーションであり、サブアプリケーションは広告に関するアプリケーション、時事ネタに関するアプリケーションなどである。

関連技術のマイクロフロントエンドソリューションでは、ルーティングサービスはＮｇｉｎｘサービスを使用して転送されるため、効率が低下し、センタールーティングはＮｇｉｎｘサービスの安定性に依存しており、ディザスタリカバリ処理方案は複雑であり、ＮｇｉｎｘソリューションはＮｇｉｎｘサービスの構成に高度に依存しており、構成の変更はセンタールーティングＮｇｉｎｘサービスを再起動する必要があり、メンテナンスコストが高く、通信メカニズムが単一であり、これにより、アプリケーションが多くなると、イベント管理が難しくなり、Ｉｆｒａｍｅを利用してアプリケーションローダーとすることで、サブアプリケーションに対するオーケストレーションと制御能力が不足する。関連技術のマイクロフロントエンドソリューションでは、マルチフロントエンドフレームワークにおけるサブアプリケーションの実行能力、マルチレベルルーティングにおけるサブアプリケーションのアクティブ化能力、メインアプリケーションによるサブアプリケーションの能動的な呼び出し、アクティブ化の能力を考慮せず、リソースのクロスドメインソリューションを提供しない。関連技術におけるマイクロフロントエンドソリューションは、リソースが統一的にデプロイされており、リソースを分散型でデプロイされた後に、フロントエンドがクロスドメインでリソースを呼び出す問題を解決せず、該リソースは、インターフェース要求、プライベート静的リソース、コンテンツ配信ネットワーク（ＣＤＮ：Ｃｏｎｔｅｎｔ Ｄｅｌｉｖｅｒｙ Ｎｅｔｗｏｒｋ）静的リソース、Ｗｅｂ Ｗｏｒｋｅｒリソースなどを含むが、これらに限定されない。

本出願の実施例は、マイクロフロントエンドシステムを提供し、該システムは、アプリケーションローダーモジュールを提供し、該アプリケーションローダーモジュールは、Ｖｕｅフレームワーク、Ｒｅａｃｔフレームワークなどの各異なるフレームワークのフロントエンドアプリケーションをロードし、ＪａｖａＳｃｒｉｐｔサンドボックスメカニズムを実現し、ＪＳ環境隔離を保証するように構成される。該システムはさらに、サブアプリケーションＷｅｂＷｏｒｋｅｒのクロスドメイン処理を提供し、サブアプリケーションのパッケージングにおけるＣＳＳプレフィックスの入れ込み、サブアプリケーションの実行時のＣＳＳプレフィックスの入れ込み、サブアプリケーションのＳｈａｄｏｗＤｏｍ方式でのロードなどによってＣＳＳ隔離を実現し、Ｐｒｏｐｓ伝送、Ｃｕｓｔｏｍ Ｅｖｅｎｔ、ＰｏｓｔＭｅｓｓａｇｅを含む３つの親子アプリケーション通信メカニズムを提供し、ルーティング登録サービスを提供し、中心化のルーティング発見能力を提供し、オリジナルのＩｆｒａｍｅでの実行を互換性があるようにサポートする。

以下、本出願の実施例が提供するマイクロフロントエンドシステムの例示的な応用を説明し、図１は、本出願の実施例によるマイクロフロントエンドシステムの構成の構造的模式図であり、図１に示すように、該マイクロフロントエンドシステム１００は、ルーティング登録サービス１０１、コマンドラインツール１０２及びマイクロフロントエンド実行フレームワーク１０３を含み、ルーティング登録サービス１０１は、独立的にメンテナンス・実行するＮｏｄｅバックエンドサービスであり、メインアプリケーションのマイクロフロントエンド実行フレームワークに、サブアプリケーションのルーティング情報、サブアプリケーションのロード方式及びサブアプリケーションのデプロイメント情報を提供するように構成される。ルーティング登録サービスを提供することにより、独立的にメンテナンス・実行可能なＮｏｄｅサービスとして、優れた容量拡張、ディザスタリカバリ能力を提供し、マイクロフロントエンドのサブアプリケーションの登録をメンテナンスし、及びルーティングをロードする。

例として、ルーティング登録サービスは、ハイパーテキスト伝送プロトコル（ＨＴＴＰ：Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）サービスを提供するサーバであり得、実際に実現する時に、Ｎｏｄｅ．ｊｓによって実現され得、Ｋｏａフレームワークによりルーティングの記録、ルーティングの削除、ルーティングのクエリ、ログイン認証などの１セットの機能を備えたウェブサーバを実現し、データベースは、リレーショナルデータベース管理システム（ＭｙＳＱＬなど）を使用する。ルーティング登録サービス１０１は、任意のサーバ又は言語によって同じ機能を実現するサービスであってもよく、例えば、Ｊａｖａ Ｓｐｒｉｎｇ Ｃｌｏｕｄ、Ｃ＋＋ Ｓｅｒｖｅｒ Ｋｉｔなどが挙げられる。

該ルーティング登録サービスは、独立的にメンテナンス・実行するＮｏｄｅバックエンドサービスであるため、該ルーティング登録サービスにはロードバランシングサービスを前置きすることもでき、ネットワーク要求を取得した後、各ルーティング登録サービスの負荷に基づいて、ネットワーク要求を負荷の小さいルーティング登録サービスに割り当てることができ、複数のルーティング登録サービスの負荷がいずれも大きい場合に、優れた容量拡張及びディザスタリカバリ能力を提供することもできる。

コマンドラインツール１０２は、コマンドラインによりサブアプリケーション新規作成機能、サブアプリケーションアクセス機能、サービス登録機能を提供するように構成される。

例として、Ｉｎｑｕｉｕｒｅｒ．ｊｓにより、ユーザがコマンドラインと対話するためのツール、即ち該コマンドラインツール１０２を提供することができる。実現するときに、該コマンドラインツールは、コマンドラインインターフェース（ＣＬＩ：ｃｏｍｍａｎｄ－ｌｉｎｅ ｉｎｔｅｒｆａｃｅ）ツールであってもよく、ｎｐｍライブラリ又はグラフィカルユーザインターフェース（ＧＵＩ：Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）ツールであってもよい。該コマンドラインツール１０２により、ユーザが入力した、ユーザのサブアプリケーション作成、サブアプリケーションアクセスなどのコマンドを受信し、受信されたコマンドに基づいてサービス登録を行うことができる。

マイクロフロントエンド実行フレームワーク１０３は、メインアプリケーションで実行されるフレームワークであり、取得されたネットワーク要求に基づいてサブアプリケーションをロードして実行し、マルチフレームワークでのサブアプリケーション実行能力を提供することができるように構成される。

例として、メインアプリケーションは、マイクロフロントエンド実行フレームワークにアクセスする任意のアプリケーションである。実現する時に、マイクロフロントエンド実行フレームワークは、Ｓｉｎｇｌｅ－ＳＰＡに基づいてマルチフレームサブアプリケーションロード能力を提供することができる。

本出願の実施例によって提供されるマイクロフロントエンドシステムは、ルーティング登録サービス、コマンドラインツール及びマイクロフロントエンド実行フレームワークを含み、ここで、ルーティング登録サービスは、独立的にメンテナンス・実行するＮｏｄｅバックエンドサービスであり、このようにして、優れた容量拡張及びディザスタリカバリ能力を提供することができ、該ルーティング登録サービスは、メインアプリケーションのマイクロフロントエンド実行フレームワークに、サブアプリケーションのルーティング情報、ロード方式及びサブアプリケーションのデプロイメント情報を提供する。コマンドラインツールは、コマンドラインによりサブアプリケーション新規作成機能、サブアプリケーションアクセス機能、サービス登録機能を提供するように構成される。マイクロフロントエンド実行フレームワーク１０３は、メインアプリケーションで実行されるフレームワークであり、取得されたネットワーク要求に基づいてサブアプリケーションをロードして実行し、マルチフレームワークでのサブアプリケーション実行能力を提供することができるように構成される。

いくつかの実施例では、図１に示すように、マイクロフロントエンドシステムは、ルーティング登録サービスに対応するフロントエンドインターフェース１０４をさらに含み、フロントエンドインターフェース１０４により、サブアプリケーション登録に設定する必要があるサブアプリケーション登録情報を取得し、サブアプリケーション登録情報をルーティング登録サービスに送信する。

サブアプリケーション登録情報は、サブアプリケーションフレームワーク、サブアプリケーションルーティングモード及びサブアプリケーションロードモードを含む。例えば、サブアプリケーションフレームワークはＶｕｅ、Ｒｅａｃｔなどを含むことができ、サブアプリケーションルーティングモードはハッシュモード（ｈａｓｈ）、履歴（ｈｉｓｔｏｒｙ）モードなどを含むことができ、サブアプリケーションロードモードは、ＪＳロードモード、ＣＳＳロードモード、ＨＴＭＬロードモードなどを含むことができる。

いくつかの実施例では、サブアプリケーション登録情報は、サービス名、サブアプリケーションローカル開発環境アドレス、サブアプリケーションオンライン環境アドレスなどをさらに含むことができる。

ルーティング登録サービス１０１は、サブアプリケーション登録情報を受信し、サブアプリケーション登録情報に基づいてサブアプリケーションを登録するように構成される。

いくつかの実施例では、該コマンドラインツール１０２は、サブアプリケーション新規作成コマンドを受信し、サブアプリケーションのルーティング情報、リソース情報、及びサブアプリケーションテンプレート情報を取得するように構成される。

本出願の実施例では、サブアプリケーションのルーティング情報は、サブアプリケーションリソースアドレス及びサブアプリケーションリソース登録パスを含むことができ、サブアプリケーションのリソース情報は、サブアプリケーションリソース名、サブアプリケーションリソースタイプを含むことができ、サブアプリケーションテンプレート情報は、テンプレート識別子を含むことができる。

コマンドラインツール１０２は、サブアプリケーションテンプレート情報に基づいてサブアプリケーションテンプレートを生成し、ルーティング登録サービス１０１にサブアプリケーション新規作成要求を送信し、サブアプリケーション新規作成要求にルーティング情報及びリソース情報が含まれる。いくつかの実施例では、ルーティング登録サービス１０１は、サブアプリケーション新規作成要求を受信した後、該サブアプリケーション新規作成要求に含まれるルーティング情報及びリソース情報に基づいてサブアプリケーションを作成する。

本出願の実施例では、コマンドラインツール１０２がサブアプリケーション新規作成要求をルーティング登録サービスに送信した後、コマンドラインツール１０２はサブアプリケーションデプロイメント要求をデプロイメントサーバに送信し、デプロイメントサーバはデプロイメント要求におけるサブアプリケーションリソースアドレスに基づいてリソースのデプロイメントを行う。

いくつかの実施例では、コマンドラインツール１０２は、さらにサブアプリケーションアクセスコマンドを受信し、サブアプリケーションのルーティング情報及びリソース情報を取得し、サブアプリケーションアクセス要求をルーティング登録サービス１０１に送信するように構成され、サブアプリケーションアクセス要求に、サブアプリケーションのルーティング情報及びリソース情報が含まれる。

ルーティング登録サービス１０１は、さらにサブアプリケーションアクセス要求を受信し、サブアプリケーションのルーティング情報及びリソース情報に基づいてサブアプリケーション登録を行うように構成される。

いくつかの実施例では、図１に示すマイクロフロントエンド実行フレームワーク１０３の構成構造は、図２に示すように、基礎機能ライブラリモジュール１０３１、通信モジュール１０３２、統一ルーティングモジュール１０３３、サブアプリケーションロードモジュール１０３４及びサブアプリケーション実行モジュール１０３５を含み、ここで、
基礎機能ライブラリモジュール１０３１は、パブリックメソッド及びパブリックコンポーネントを提供し、グローバル変数及び関数の方式により、サブアプリケーションに使用されるパブリックメソッド及びパブリックコンポーネントをサブアプリケーションに入れ込むように構成される。

いくつかの実施例では、基礎機能ライブラリモジュールは、サブアプリケーションに使用される一般的なＰｏｌｙｆｉｌｌｉｇも提供することができる。

通信モジュール１０３２は、メインアプリケーションからサブアプリケーションへの、サブアプリケーションからサブアプリケーションへの、及びサブアプリケーションからメインアプリケーションへの通信メカニズムをサポートするように構成される。

本出願の実施例では、メインアプリケーションからサブアプリケーションへの通信メカニズムは、プロップＰｒｏｐｓ伝送とカスタムイベントＣｕｓｔｏｍ Ｅｖｅｎｔ伝送を含み、サブアプリケーションからサブアプリケーションへの通信メカニズムは、異なるソースのスクリプトの非同期ＰｏｓｔＭｅｓｓａｇｅ伝送を含み、サブアプリケーションからメインアプリケーションへの通信は、Ｃｕｓｔｏｍ Ｅｖｅｎｔ伝送を含む。Ｐｒｏｐｓ伝送は、応答式の双方向データ伝送能力を提供することができる。Ｃｕｓｔｏｍ Ｅｖｅｎｔは、コンポーネントに基づいてイベントの配布と登録を定義し、アプリケーションが多くなる場合の無関係なイベントの影響を回避することができる。ＰｏｓｔＭｅｓｓａｇｅは、ブロードキャストクラスのメッセージ通知を実現するために、グローバルなイベントの送受信を提供する。本出願の実施例では、各通信次元に応答する実現ソリューションがあり、手段が豊富で、副作用が小さい。

本出願の実施例は、Ｐｒｏｐｓ伝送、Ｃｕｓｔｏｍ Ｅｖｅｎｔ伝送、及びＰｏｓｔＭｅｓｓａｇｅ伝送を含む３種類の通信サポートを提供し、Ｐｒｏｐｓ伝送は、応答式の双方向データ伝送能力を提供することができ、Ｃｕｓｔｏｍ Ｅｖｅｎｔ伝送は、コンポーネントに基づいてイベントの配布と登録を定義し、アプリケーションが多くなる場合の無関係なイベントの影響を回避することができ、ＰｏｓｔＭｅｓｓａｇｅ伝送は、グローバルなイベントの送受信を提供し、ブロードキャストクラスのメッセージ通知を実現するように構成され、各通信次元に応答する実現ソリューションがあり、手段が豊富で、副作用が小さい。

統一ルーティングモジュール１０３３は、ブラウザルーティング変更を監視するように構成される。

実現するときに、統一ルーティングモジュール１０３３は、Ｓｉｎｇｌｅ－ＳＰＡを使用してブラウザルーティング変更を監視し、指定されたフレームワークにおけるサブアプリケーション又はメインアプリケーションサブパスをロード、アクティブ化、及び実行し、メインアプリケーション初期化時に、ルーティング登録サービスから該統一ルーティングモジュール１０３３におけるサブアプリケーション登録パス、リソースなどの情報をプルする。

サブアプリケーションロードモジュール１０３４は、ルーティング登録サービスから取得されたサブアプリケーションリソースアドレスに基づいて、サブアプリケーションリソースアドレスに対応するリソースを取得してロードするように構成される。

例として、サブアプリケーションロードモジュール１０３４は、サブアプリケーションリソースアドレスに対応するリソースをロードする場合、サブアプリケーション登録情報におけるサブアプリケーションロードモードに従ってサブアプリケーションリソースをロードし、ここで、該サブアプリケーションロードモジュールがサブアプリケーションをロードするモードは、少なくともＨＴＭＬエンティティモード、ＪＳエンティティモード及びＩｆｒａｍｅモードを含む。ロードモードがＨＴＭＬエンティティモードである場合、ＨＴＭＬファイルをロードし、ロードモードがＪＳエンティティモードである場合、ＪＳファイルをロードし、ロードモードがＩｆｒａｍｅモードである場合、直接ＵＲＬをＩｆｒａｍｅに埋め込んで開く。

いくつかの実施例では、サブアプリケーションロードモジュール１０３４は、サブアプリケーションリソースアドレスに対応するリソースを取得した後、該リソースに基づいてサブアプリケーションのビジネスコードを取得し、取得したサブアプリケーションのビジネスコードを解析し、解析後のビジネスコードをサブアプリケーション実行モジュール１０３５に伝送する。

サブアプリケーション実行モジュール１０３５は、サブアプリケーションリソースアドレスに対応するリソースを実行して、サブアプリケーションのページをレンダリングするように構成される。

サブアプリケーション実行モジュール１０３５は、実行環境サンドボックスを含み、サブアプリケーション実行モジュールで解析後のビジネスコードを取得し、解析後のビジネスコードを実行環境サンドボックスで実行する。

実際に実現するときに、実行環境サンドボックスは、ＪＳサンドボックス、ＣＳＳサンドボックス及びＷｅｂＷｏｒｋｅｒサンドボックスを含む。ここで、ｗｉｔｈ語句とプロキシを使用して、基本的なＪＳサンドボックスを実現し、サブアプリケーションが制御可能である前提で基本的な安全を実現し、スタック検査、キーワード検査によりスコープからのエスケープを克服する。ここで、プロキシはサブアプリケーションがアクセスできるオブジェクト集合であり、ＪＳサンドボックスは、サブアプリケーションのビジネスコードがプロキシ内のアクセス可能なオブジェクトのみにアクセスすることができ、他のサブアプリケーション又はメインアプリケーションのオブジェクトにアクセスすることができないようにする。解析後のビジネスコードがＪＳサンドボックスで実行される場合、解析後のビジネスコードは、プロキシをグローバルルートオブジェクトとしてサンドボックスに入れて実行され、つまり、ビジネスコードはプロキシのオブジェクトと属性にのみアクセスでき、外層の他の変数に影響を与えず、安全な隔離を実現する。

本出願の実施例では、３つのＣＳＳサンドボックス手段が提供される。１つ目は、サブアプリケーションのｗｅｂｐａｃｋでのパッケージングによるプレフィックスに基づく手段であり、サブアプリケーションのｗｅｂｐａｃｋでのパッケージングによるプレフィックスとは、各サブアプリケーションのスタイルに個別の命名空間を割り当てることであり、このように、スタイルが互いに影響するのを回避する。２つ目は、サブアプリケーションの実行時のプレフィックスに基づく手段であり、サブアプリケーションの実行時にプレフィックスをサブアプリケーションのスタイルに動的に追加することで、スタイルの衝突を回避する。３つ目は、ＳｈａｄｏｗＤｏｍに基づく手段であり、ＳｈａｄｏｗＤｏｍに基づくＣＳＳサンドボックスは、ブラウザレベルのスタイル隔離能力を提供することができ、完全な隔離を実現することができる。

ＷｅｂＷｏｒｋｅｒサンドボックスは、ＷｅｂＷｏｒｋｅｒに割り当てられたスクリプトファイルをインラインで実行して、ＷｅｂＷｏｒｋｅｒのクロスドメインでの呼び出しを実現するように構成される。

サブアプリケーションリソースロードモジュールは、リソースをロードする時に＊．ｗｏｒｋｅｒ．ｊｓのファイルをハイジャックし、該ファイルをテキストコンテンツとしてブラウザのメモリにロードし、ＷｅｂＷｏｒｋｅｒサンドボックスを使用してＷｅｂＷｏｒｋｅｒのスクリプトファイル（＊．ｗｏｒｋｅｒ．ｊｓ）をインラインで実行し、インラインで実行されるＷｅｂＷｏｒｋｅｒスクリプトファイルがクロスドメインの問題を引き起こさないため、ＷｅｂＷｏｒｋｅｒのクロスドメインの問題が解決される。

いくつかの実施例では、マイクロフロントエンドシステムは、クロスドメインリソース共有をサポートするサーバをさらに含む。実現するときに、該サーバはクロスオリジンリソース共有（ＣＯＲＳ：Ｃｒｏｓｓ－ｏｒｉｇｉｎ Ｒｅｓｏｕｒｃｅ Ｓｈａｒｉｎｇ）ヘッダーを自動的に含ませるため、クロスドメインリソース共有をサポートすることができ、これにより、ブラウザはプライベート静的リソース、ＣＤＮ静的リソースにドメインを跨いでアクセスすることができる。

本出願の実施例は、クロスドメインをサポートするために、インターフェースリソースを含むサーバ側のＣＯＲＳソリューションを提供し、ＣＤＮ静的リソースでＣＯＲＳソリューションを提供し、ドメインを跨いでｗｏｒｋｅｒを呼び出す問題を解決するために、ＷｅｂＷｏｒｋｅｒはインライン構築ローダーとインライン実行ローダーを提供する。本出願の実施例はさらに、サブアプリケーションのロード及び呼び出しを加速するために、キャッシュ、プリロード、ＷｅｂＷｏｒｋｅｒなどの手段を提供する。

いくつかの実施例では、図２に示すように、マイクロフロントエンド実行フレームワーク１０３は、データ管理モジュール１０３６、性能監視モジュール１０３７及びエラー処理モジュール１０３８をさらに含み、ここで、
データ管理モジュール１０３６は、Ｐｒｏｐｓ伝送メカニズムによって提供されるデータにより、データ双方向バインディング機能を実現し、それによって、親子アプリケーションのデータを共有するように構成され。

本出願の実施例では、親子アプリケーションは同じ実行環境にロードされ、メインアプリケーションは、監視機能を有するオブジェクトをサブアプリケーションに渡し、サブアプリケーションが変更された場合、該オブジェクトによって監視され得、それによって、親子アプリケーションデータの共有を実現することができる。

性能監視モジュール１０３７は、サブアプリケーションのロード時間長及び実行時間長を監視するように構成される。

実現するときに、メインアプリケーションは、予め設定された関数により、サブアプリケーションのロード時間長及び実行時間長などの情報を監視する。

エラー処理モジュール１０３８は、ロード及び実行中におけるサブアプリケーションのエラー情報を監視及び処理するように構成される。

実現するときに、メインアプリケーションはｗｉｎｄｏｗ．ａｄｄＥｖｅｎｔＬｉｓｔｅｎｅｒ（‘ｅｒｒｏｒ’,ｅｒｒｏｒＨａｎｄｌｅｒ）、ｗｉｎｄｏｗ．ａｄｄＥｖｅｎｔＬｉｓｔｅｎｅｒ（‘ｕｎｈａｎｄｌｅｄｒｅｊｅｃｔｉｏｎ’,ｅｒｒｏｒＨａｎｄｌｅｒ）を登録することで、サブアプリケーションのエラーを監視及び処理し、それによって、サブアプリケーションのエラー情報をタイムリーに処理し、マイクロフロントエンドシステムの信頼性を保証することができる。

前述の実施例で提供されるマイクロフロントエンドシステムに基づいて、本出願の実施例は、マイクロフロントエンドシステムに基づくサブアプリケーションロード方法をさらに提供し、該方法は、上記実施例で提供されるマイクロフロントエンドシステムに適用されるべきであり、図３は、本出願の実施例によるマイクロフロントエンドシステムに基づくサブアプリケーションロード方法の実現フローの模式図であり、図３に示すように、該方法は以下のステップを含む。

ステップ３０１において、ネットワークアクセス要求を取得する。

例として、該ネットワークアクセス要求にＵＲＬアドレスが含まれる。該ネットワークアクセス要求は、ユーザのネットワークアクセス操作によってトリガーされてもよい。該機能ネットワークアクセス要求は、メインアプリケーションにアクセスする要求として構成されてもよく、サブアプリケーションにアクセスする要求であってもよい。該ネットワークアクセス要求がサブアプリケーションにアクセスするネットワークアクセス要求である場合、ユーザがブラウザにメインアプリケーションのＵＲＬアドレスを入力し、ブラウザがメインアプリケーションインターフェースをレンダリングした後、ユーザはメインアプリケーションインターフェースで提供されるサブアプリケーションのアイコンによってサブアプリケーションへのネットワークアクセス要求をトリガーすることであり得る。

本出願の実施例では、ステップＳ３０１の前に、該マイクロフロントエンドシステムは、既にメインアプリケーションのデプロイメント及びルーティング登録サービスのデプロイメントを完了し、ＣＬＩツールによりサブアプリケーションの作成及び登録を完了した。

ステップ３０２において、ＵＲＬアドレスに基づいて、マイクロフロントエンドシステムのルーティング登録サービスから、対応するルーティング情報をプルする。

例として、ステップＳ３０２を実現する場合、ＵＲＬアドレスをルーティング登録サービスに送信してもよく、ルーティング登録サービスは、該ＵＲＬアドレスに基づいてアクセスすべきアプリケーション識別子を決定し、次に該アプリケーション識別子に基づいて対応するルーティング情報をプルする。

ステップＳ３０３において、ルーティング情報に基づいて、アクセス対象ページがサブアプリケーションのページであると決定した場合、マイクロフロントエンドシステムのサブアプリケーションロードモジュールは、ルーティング情報に基づいて、ルーティング登録サービスからルーティング情報に対応するサブアプリケーションリソースを取得する。

例として、アプリケーションに対応するルーティング情報を取得した後、アクセス対象ページがサブアプリケーションのページであると決定した場合、ルーティング登録サービスは、該ルーティング情報に基づいて、対応するサブアプリケーションリソースを取得することができ、該サブアプリケーションリソースは、例えばＣＳＳ、ＪＳなどの静的リソースドキュメントであり得る。

ステップＳ３０４において、サブアプリケーションリソースをロードする必要がある場合、サブアプリケーションロードモジュールは、サブアプリケーションリソースをロードする。

本出願の実施例では、サブアプリケーションロードモジュールがサブアプリケーションリソースを取得した後、まず該サブアプリケーションリソースをロードする必要があるかどうかを判断する必要があり、サブアプリケーションリソースをロードする必要がある場合、サブアプリケーションのロードモードに基づいてサブアプリケーションリソースをロードし、サブアプリケーションリソースをロードする必要がないと決定した場合、該サブアプリケーションリソースが既にロードされていることを意味し、このとき、該サブアプリケーションリソースを直接実行して、サブアプリケーションのページをレンダリングする。

ステップＳ３０５において、マイクロフロントエンドシステムのサブアプリケーション実行モジュールは、サブアプリケーションリソースを実行して、サブアプリケーションのページをレンダリングする。

いくつかの実施例では、サブアプリケーションロードモジュールは、サブアプリケーションリソースを取得した後、該サブアプリケーションリソースに基づいてサブアプリケーションのビジネスコードを取得し、取得したサブアプリケーションのビジネスコードを解析し、解析後のビジネスコードをサブアプリケーション実行モジュールに伝送する。サブアプリケーション実行モジュールは、解析後のビジネスコードを得、解析後のビジネスコードを自身の実行環境サンドボックスで実行して、サブアプリケーションのページをレンダリングする。

実際に実現するときに、実行環境サンドボックスは、ＪＳサンドボックス、ＣＳＳサンドボックス及びＷｅｂＷｏｒｋｅｒサンドボックスを含む。ここで、ｗｉｔｈ語句とプロキシを使用して、基本的なＪＳサンドボックスを実現し、サブアプリケーションが制御可能である前提で基本的な安全を実現し、スタック検査、キーワード検査によりスコープからのエスケープを克服する。ここで、プロキシはサブアプリケーションがアクセスできるオブジェクト集合であり、ＪＳサンドボックスは、サブアプリケーションのビジネスコードがプロキシ内のアクセス可能なオブジェクトのみにアクセスすることができ、他のサブアプリケーション又はメインアプリケーションのオブジェクトにアクセスすることができないようにすることができる。解析後のビジネスコードがＪＳサンドボックスで実行される場合、解析後のビジネスコードはプロキシをグローバルルートオブジェクトとしてサンドボックスに入れて実行され、つまり、ビジネスコードはプロキシのオブジェクトと属性にのみアクセスでき、外層の他の変数に影響を与えず、安全な隔離を実現する。

本出願の実施例では、３つのＣＳＳサンドボックス手段が提供される。１つ目は、サブアプリケーションのｗｅｂｐａｃｋでのパッケージングによるプレフィックスに基づく手段であり、サブアプリケーションのｗｅｂｐａｃｋでのパッケージングによるプレフィックスとは、各サブアプリケーションのスタイルに個別の命名空間を割り当てることであり、このように、スタイルが互いに影響するのを回避する。２つ目は、サブアプリケーションの実行時のプレフィックスに基づく手段であり、サブアプリケーションの実行時にアプリケーションスタイルを動的にロード及びアンロードすることで、スタイルの衝突を回避する。３つ目は、ＳｈａｄｏｗＤｏｍに基づく手段であり、ＳｈａｄｏｗＤｏｍに基づくＣＳＳサンドボックスは、ブラウザレベルのスタイル隔離能力を提供することができ、完全な隔離を実現することができる。

ＷｅｂＷｏｒｋｅｒサンドボックスは、ＷｅｂＷｏｒｋｅｒに割り当てられたスクリプトファイルをインラインで実行して、ＷｅｂＷｏｒｋｅｒのクロスドメインでの呼び出しを実現するように構成される。サブアプリケーションリソースロードモジュールは、リソースをロードする時に＊．ｗｏｒｋｅｒ．ｊｓのファイルをハイジャックし、該ファイルをテキストコンテンツとしてブラウザのメモリにロードし、ＷｅｂＷｏｒｋｅｒサンドボックスを使用してＷｅｂＷｏｒｋｅｒのスクリプトファイル（＊．ｗｏｒｋｅｒ．ｊｓ）をインラインで実行し、インラインで実行されるＷｅｂＷｏｒｋｅｒスクリプトファイルがクロスドメインの問題を引き起こさないため、ＷｅｂＷｏｒｋｅｒのクロスドメインの問題が解決される。

本出願の実施例で提供されるマイクロフロントエンドシステムに基づくサブアプリケーションロード方法では、ネットワークアクセス要求を取得した後、ネットワークアクセス要求に含まれるＵＲＬアドレスに基づいて、マイクロフロントエンドシステムのルーティング登録サービスから、対応するルーティング情報をプルし、ルーティング情報に基づいて、アクセス対象ページがサブアプリケーションのページであると決定した場合、マイクロフロントエンドシステムのサブアプリケーションロードモジュールは、ルーティング情報に基づいてルーティング登録サービスからルーティング情報に対応するサブアプリケーションリソースを取得し、サブアプリケーションリソースをロードする必要がある場合、サブアプリケーションロードモジュールはサブアプリケーションリソースをロードし、次にマイクロフロントエンドシステムのサブアプリケーション実行モジュールはサブアプリケーションリソースを実行して、サブアプリケーションのページをレンダリングする。

いくつかの実施例では、図４に示すように、ステップＳ３０４の前に、該マイクロフロントエンドシステムに基づくサブアプリケーションロード方法は、ステップＳ００３をさらに含む。

ステップＳ００３において、サブアプリケーションリソースがプリロードされたか、又は開かれたかどうかを決定する。

例として、サブアプリケーションリソースがプリロードされておらず、且つ開かれていない場合、サブアプリケーションリソースをロードする必要があると決定し、このとき、ステップＳ３０４に進み、サブアプリケーションリソースがプリロードされ、又は開かれた場合、サブアプリケーションリソースを再ロードする必要がないと決定し、このとき、ステップＳ３０５に進む。このようにして、サブアプリケーションのロードと呼び出しを加速することができる。

いくつかの実施例では、サブアプリケーションがロードされる前に、まずサブアプリケーションの登録及びデプロイメントを実行する必要があり、サブアプリケーション登録プロセスは、次のステップによって実現され得る。

ステップＳ００１において、サブアプリケーション登録に設定する必要があるサブアプリケーション登録情報を取得し、サブアプリケーション登録情報をルーティング登録サービスに送信する。

例として、サブアプリケーション登録情報は、少なくともサブアプリケーションフレームワーク、サブアプリケーションルーティングモード、及びサブアプリケーションロードモードを含む。

マイクロフロントエンドシステムは、ルーティング登録サービスに対応するフロントエンドインターフェースを含むことができ、サブアプリケーションを作成することと、サブアプリケーションにアクセスすることとを行うように構成されるコマンドラインツールをさらに含むことができ、対応して、ステップＳ００１を実現する場合、２つの実現方式がある。

第一の実現方式において、ルーティング登録サービスに対応するフロントエンドインターフェースにより、サブアプリケーション登録に対する入力操作を取得し、入力操作に基づいてサブアプリケーション登録情報を決定する。

第一の方式に基づいてサブアプリケーション登録情報を取得する場合、まず該フロントエンドインターフェースを開く操作指示に基づいて該フロントエンドインターフェースを表示し、該フロントエンドインターフェースにより、サブアプリケーション登録に対する入力操作を受信し、該入力操作はサブアプリケーション登録に設定する必要があるパラメータを入力することであり、例えば、パラメータは、サービス名、サブアプリケーションフレームワーク、サブアプリケーションローカル開発環境アドレス、サブアプリケーションオンライン環境アドレス、サブアプリケーション登録サブルーティング、サブアプリケーションルーティングモード（ｈａｓｈ又はｈｉｓｔｏｒｙ）、サブアプリケーションロードモードなどを含むことができる。

いくつかの実施例では、該フロントエンドインターフェースは、登録を決定するためのグラフィカルコントロールも提供し、サブアプリケーション登録情報に対する設定が完了したことがユーザによって決定した後、該グラフィカルコントロールをクリック又はタッチして、サブアプリケーション登録情報をルーティング登録サービスに送信することができる。サブアプリケーション登録情報をルーティング登録サービスに送信する場合、ルーティング登録サービスにサブアプリケーション登録のＨＴＴＰ要求を送信してもよく、該ＨＴＴＰ要求にサブアプリケーション登録情報を含むことができる。

第二の実現方式において、コマンドラインツールによりサブアプリケーション新規作成コマンドを受信し、サブアプリケーション作成に対する入力操作を取得し、入力操作に基づいてサブアプリケーション登録情報を決定する。

第一の実現方式と同様に、コマンドラインツールに基づいてサブアプリケーション登録情報を取得する場合、まずコマンドラインツールを起動し、次に該コマンドラインツールによりサブアプリケーション新規作成コマンドを受信し、さらにサブアプリケーション作成に対する入力操作を取得し、該入力操作はサブアプリケーション登録に設定する必要があるパラメータを入力することであり、続いて、該入力操作に基づいてサブアプリケーション登録情報を取得し、サブアプリケーション登録情報は、例えば、サブアプリケーションリソース名、サブアプリケーションリソースアドレス、サブアプリケーションリソースタイプ、サブアプリケーションリソース登録パスなどの情報を含むことができ、実現するときに、コマンドラインツールによりサブアプリケーションテンプレート識別子を選択する必要もあり、次にコマンドラインツールによって対応するテンプレートを自動的に生成し、サブアプリケーションリソースアドレス、サブアプリケーションリソース登録アドレスなどの情報を入れ込む。サブアプリケーション登録情報をルーティング登録サービスに送信する場合、情報送信コマンドを入力することで、該情報送信コマンドに基づいてサブアプリケーション登録情報をルーティング登録サービスに送信することができる。

ステップＳ００２において、ルーティング登録サービスは、サブアプリケーション登録情報を受信し、サブアプリケーション登録情報に基づいてサブアプリケーションを登録する。

上述のステップＳ００１～Ｓ００２により、該マイクロフロントエンドシステムにより、自らでサブアプリケーションのルーティング情報とリソース情報を登録することができ、それによってサブアプリケーション登録の柔軟性を向上させる。

いくつかの実施例では、図３に示すステップＳ３０４「サブアプリケーションリソースをロードする必要がある場合、サブアプリケーションロードモジュールはサブアプリケーションリソースをロードする」は、以下のステップによって実現され得る。

ステップＳ３０４１において、サブアプリケーションリソースをロードする必要がある場合、サブアプリケーションのフレームワーク識別子及びリソースロードモードを取得する。

例として、サブアプリケーションのフレーム識別子は、Ｖｕｅ、Ｒｅａｃｔなどを含むことができ、リソースロードモードは、ＪＳエンティティロードモード、ＣＳＳエンティティロードモード、Ｉｆｒａｍｅロードモードなどを含むことができる。

ステップＳ３０４２において、リソースロードタイプに基づいて、フレームワーク識別子に対応するサブアプリケーションフレームワークでサブアプリケーションリソースをロードする。

例として、ロードモードがＨＴＭＬエンティティモードである場合、ＨＴＭＬファイルをロードし、ロードモードがＪＳエンティティモードである場合、ＪＳファイルをロードし、ロードモードがＩｆｒａｍｅモードである場合、直接ＵＲＬをＩｆｒａｍｅに埋め込んで開く。

いくつかの実施例では、図５に示すように、ステップＳ３０２の後、以下のステップも実行され得る。

ステップＳ２０１において、ルーティング情報に基づいて、アクセス対象ページがメインアプリケーションページであるかどうかを決定する。

例として、ルーティング情報に基づいてアクセス対象ページがメインアプリケーションページであると決定した場合、ステップＳ２０２を実行し、ルーティング情報に基づいて、アクセス対象ページがサブアプリケーションのページであると決定した場合、ステップＳ３０３に進む。

ステップ２０２において、ライフサイクルに基づいてメインアプリケーションに現在マウントされているサブアプリケーションを決定する。

ステップＳ２０３において、現在マウントされているサブアプリケーションからレンダリングするべき目標サブアプリケーションを決定する。

例として、ステップＳ２０３は、予め設定されたルールに従って、現在マウントされているサブアプリケーションからレンダリングするべき少なくとも１つの目標サブアプリケーションを決定するステップであってもよく、例えば、現在マウントされているサブアプリケーションからアクセス数が最も多い１つ又は複数のサブアプリケーションを選択して目標サブアプリケーションとして決定することができる。

ステップＳ２０４において、公開されるロード関数と目標サブアプリケーションに基づいて、ルーティング切り替えをシミュレートし、目標サブアプリケーションのサブアプリケーションリソースとメインアプリケーションリソースを取得する。

例として、アクセス対象ページがメインアプリケーションページである場合、まずルーティング情報に基づいてメインアプリケーションリソースを取得する。本出願では、ロード関数が公開されるものであるため、メインアプリケーションはロード関数を能動的に呼び出すことができ、メインアプリケーションが公開されるロード関数を能動的に呼び出す場合、ルーティング切り替えをシミュレートすることができ、それによって、マイクロフロントエンドシステムのサブアプリケーションロードモジュールが目標サブアプリケーションのサブアプリケーションリソースを取得することをトリガーする。

ステップＳ２０５において、メインアプリケーションリソース及びサブアプリケーションリソースをロードして実行して、レンダリング済みのメインアプリケーションのページにサブアプリケーションをレンダリングする。

ステップＳ２０５を実現する場合、まずメインアプリケーションリソースをロードして実行して、メインアプリケーションインターフェースをレンダリングし、次にサブアプリケーションリソースを実行してサブアプリケーションのページもレンダリングし、このようにして、メインアプリケーションは、ルーティング登録に依存することなく、サブアプリケーションを能動的にレンダリングすることができる。

上述のステップＳ２０１～Ｓ２０５が記載される実施例では、アクセス対象ページがメインアプリケーションページである場合、メインアプリケーションのライフサイクルに基づいて現在マウントされているサブアプリケーションを決定し、予め設定されたルールに基づいて、目標サブアプリケーションを決定し、公開されるロード関数を呼び出すことで、ルーティング切り替えをシミュレートし、目標サブアプリケーションのサブアプリケーションリソースを取得し、レンダリング済みのメインアプリケーションページにサブアプリケーションのページを表示し、それによって、サブアプリケーションに対するメインアプリケーションの能動的なレンダリングを実現することができる。

次に、実際の適用シナリオにおける本出願の実施例の例示的な適用を説明する。

図６は、本出願の実施例によるマイクロフロントエンドシステムの模式図であり、図６に示すように、該マイクロフロントエンドシステムは、ルーティング登録サービス６０１、該ルーティング登録サービスに対応するフロントエンドページ、サブアプリケーションをアクセス、生成するためのＣＬＩツール６０２、及びメインアプリケーションのマイクロフロントエンド実行フレームワーク６０３を含む。

ルーティング登録サービス６０１は、マイクロフロントエンド実行フレームワーク６０３に、サブアプリケーションのルーティング情報、ロード方式及びサブアプリケーションのデプロイメント情報を提供する。

実現するときに、サブアプリケーションルーティング登録を行うためのフロントエンドインターフェースを提供してもよく、該ページにより、ルーティング登録に必要なパラメータを設定することができ、設定する必要があるパラメータは、サービス名、サブアプリケーションフレームワーク、サブアプリケーションローカル開発環境アドレス、サブアプリケーションオンライン環境アドレス、サブアプリケーション登録サブルーティング、サブアプリケーションルーティングモード（ｈａｓｈ又はｈｉｓｔｏｒｙ）、サブアプリケーションロードモードを含むが、これらに限定されない。

ルーティング登録サービス６０１は、ＨＴＴＰサービスを提供するサーバであり、主にＮｏｄｅ．ｊｓによって実現され、Ｋｏａフレームワークによりルーティングの記録、ルーティングの削除、ルーティングのクエリ、ログイン認証などの１セットの機能を備えるウェブサーバを実現し、データベースは、ＭｙＳＱＬを使用してもよく、他の形式のデータベースを使用してもよい。

実現するときに、ルーティング登録サービスはＮｏｄｅバックエンドサービスであり得、該Ｎｏｄｅバックエンドサービスによりサブアプリケーションの登録情報を受信し、アプリケーションローダーが該Ｎｏｄｅバックエンドサービスによりサブアプリケーションを解析及び発見し、情報により如何にサブアプリケーションのリソースをロードするかを決定する。複数のＮｏｄｅシングルサービスは、ＰＭ２によって起動され、ＰＭ２は、ロードバランシング機能を備えたＮｏｄｅアプリケーションプロセスマネージャであり、また、ルーティング登録サービスは、ロードバランシングサービスをさらに含むことができ、サービスのディザスタリカバリ、キープアライブ及び容量拡張能力を提供するように構成される。

ＣＬＩツール６０２は、サブアプリケーション作成、サブアプリケーションアクセス、サービス登録及びデプロイメントなどを含む機能を提供する。

実現するときに、Ｉｎｑｕｉｒｅｒ．ｊｓによりコマンドラインツールの１セットを提供し、サブアプリケーション作成、サブアプリケーションアクセス、サービス登録及びデプロイメントなどを含む機能を提供する。

サブアプリケーション作成を実現するときに、ユーザはまずコマンドラインでサブアプリケーション新規作成コマンドを入力し、サブアプリケーションリソース名、サブアプリケーションリソースアドレス、サブアプリケーションリソースタイプ、サブアプリケーションリソース登録パスを書き込み、サブアプリケーションテンプレートを選択してもよく、ＣＬＩツールは、対応するテンプレートを自動的に生成し、ルーティング情報を入れ込み、リソース情報をルーティング登録サービスに自動的に登録する。

サブアプリケーションアクセスを実現するときに、ユーザはコマンドラインでサブアプリケーションアクセスコマンドを入力し、サブアプリケーションリソース名、サブアプリケーションリソースアドレス、サブアプリケーションリソースタイプ、及びサブアプリケーションリソース登録パスを書き込むことができ、ＣＬＩツールは自動的にサブアプリケーションのエントリーファイルを検索し、メインアプリケーションに必要なライフサイクル関数を追加し、ＣＬＩツールはリソース情報をルーティング登録サービスに自動的に登録する。

サービス登録機能を実現するときに、ＣＬＩツールは、ＨＴＴＰ要求にサブアプリケーション新規作成コマンドを含ませ、サブアプリケーションリソース名、サブアプリケーションリソースアドレス、サブアプリケーションリソースタイプ、サブアプリケーションリソース登録パスなどのパラメータを書き込み、ＨＴＴＰ要求によりルーティング登録サービスに送信する。

デプロイメント機能を実現するときに、ＣＬＩツールはＨＴＴＰ要求によりデプロイメント要求をルーティング登録サービスに送信する。

マイクロフロントエンド実行フレームワーク６０３は、メインアプリケーションで実行されるフレームワークであり、メインアプリケーションは、親アプリケーション又はアプリケーションシェル（ＡＰＰ ｓｈｅｌｌ）とも呼ばれ、ＡＰＰ ｓｈｅｌｌは、パブリックリソースライブラリ、アプリケーションローダー、リソースパッケージ（Ｓｉｎｇｌｅ－ＳＰＡのパッケージ）及び実行環境サンドボックスを含む。実行環境サンドボックスは、ｊｓサンドボックス、ＷｅｂＷｏｒｋｅｒインラインサンドボックス及びＣＳＳ環境隔離サンドボックスを含む。ＡＰＰ ｓｈｅｌｌは、Ｉｆｒａｍｅモードの実行もサポートする。

メインアプリケーションは、マイクロフロントエンド実行フレームワークにアクセスする任意のアプリケーションである。

図６の６０３に示すように、該マイクロフロントエンド実行フレームワークは、基礎機能ライブラリ、通信モジュール、データ管理モジュール、性能監視モジュール、エラー処理モジュール、統一ルーティングモジュール、サブアプリケーションロードモジュール及びサブアプリケーション実行モジュールを含む。

基礎機能ライブラリは、一般的なｐｏｌｙｆｉｌｌｓ、パブリックメソッド及びコンポーネントを提供し、グローバル変数及び関数などの方式により、サブアプリケーションによって使用されるためにサブアプリケーションに入れ込む。

通信モジュールは、Ｃｕｓｔｏｍ Ｅｖｅｎｔによりイベント通信を提供し、ＰｏｓｔＭｅｓｓａｇｅによりメッセージ通信を提供し、ライフサイクルにおけるＰｒｏｐｓ伝送によりシステムデータ通信を提供する。

図７は、本出願の実施例によるマイクロフロントエンドシステムにおける通信メカニズムの模式図であり、図７に示すように、メインアプリケーションからサブアプリケーションへの通信方式はＰｒｏｐｓとＣｕｓｔｏｍ Ｅｖｅｎｔの２つの通信メカニズムを含むことができ、サブアプリケーションからメインアプリケーションへの通信方式は、Ｃｕｓｔｏｍ Ｅｖｅｎｔ（コンポーネント）とＣｕｓｔｏｍ Ｅｖｅｎｔ（ｗｉｎｄｏｗ）の２つの通信メカニズムを含むことができ、サブアプリケーション間の通信方式は、ＰｏｓｔＭｅｓｓａｇｅとブロードキャストチャネル（ＢｒｏａｄｃａｓｔＣｈａｎｎｅｌ）の２つの通信方式を含むことができる。

データ管理モジュールは、Ｐｒｏｐｓによって提供されるデータにより、データ双方向バインディング機能を実現し、親子アプリケーションのデータを共有する。

性能監視モジュールは、メインアプリケーションが関数によりサブアプリケーションのロード時間、実行時間などのデータの監視を実現するように構成される。

エラー処理モジュールは、ロード及び実行中におけるサブアプリケーションのエラー情報を監視及び処理するように構成される。

例として、メインアプリケーションはリスナーを登録することで、サブアプリケーションのエラーレポートを監視及び処理し、ここで、登録されたリスナーは、ｗｉｎｄｏｗ．ａｄｄＥｖｅｎｔＬｉｓｔｅｎｅｒ（‘ｅｒｒｏｒ’,ｅｒｒｏｒＨａｎｄｌｅｒ）及びｗｉｎｄｏｗ．ａｄｄＥｖｅｎｔＬｉｓｔｅｎｅｒ（‘ｕｎｈａｎｄｌｅｄｒｅｊｅｃｔｉｏｎ’,ｅｒｒｏｒＨａｎｄｌｅｒ）を含む。

統一ルーティングモジュールは、Ｓｉｎｇｌｅ－ＳＰＡを使用してブラウザルーティング変更を監視し、指定されたフレームワークにおけるサブアプリケーション又はメインアプリケーションサブパスをロード、アクティブ化及び実行し、メインアプリケーション初期化時にルーティング登録サービスから該統一ルーティングモジュールにおけるサブアプリケーション登録パス、リソースなどの情報をプルする。

サブアプリケーションロードモジュールは、サブアプリケーションリソースをロードするように構成される。

図８は、本出願の実施例によるサブアプリケーションロードモジュールによってサブアプリケーションリソースをロードする実現フローの模式図であり、図８に示すように、該フローは以下のステップを含む。

ステップＳ８０１において、取得したネットワーク要求に基づいて、ルーティング登録サービスからルーティング及び静的リソースをプルする。

例として、該ネットワークアクセス要求にＵＲＬアドレスが含まれ、ステップＳ８０１を実現するときに、該ＵＲＬアドレスに基づいて、ルーティング登録サービスから該ＵＲＬアドレスに対応するアプリケーション識別子を決定し、ルーティング登録サービスは、該アプリケーション識別子に基づいて、対応するルーティング情報を決定し、ルーティング情報に基づいて静的リソースを取得することができる。

ステップＳ８０２において、リソースローダーはサブアプリケーションリソースをロードする。

リソースローダーは、異なるフレームワークのサブアプリケーションをロードすることができ、ＨＴＭＬ Ｅｎｔｒｙ、ＪＳ Ｅｎｔｒｙモード、Ｉｆｒａｍｅモードをロードすることができ、ＨＴＭＬモードはＨＴＭＬにおける参照リソースにより静的ファイルをロードし、ｊｓモードはｊｓにより動的にリソースをロードし、サブアプリケーションをロードするために伝統的なＩｆｒａｍｅモードも提供する。

本出願の実施例では、性能とクロスドメインの影響を考慮して、リソースローダーはプリロード、キャッシュ、ｉｄｌｅロードなどの手段も提供することができる。

ステップＳ８０３において、リソースローダーがサブアプリケーションリソースをロードした後、リソース情報を登録する。

例として、リソースローダーがサブアプリケーションリソースをロードした後、ロードしたサブアプリケーションリソース情報をメモリに登録する。

サブアプリケーションロードモジュールは、リソースローダーとリソースパッケージを含み、リソースパッケージは、Ｓｉｎｇｌｅ－ＳＰＡに基づくパッケージであり、マルチフロントエンドフレームワークにおけるサブアプリケーションの実行能力を提供することができ、Ｓｉｎｇｌｅ－ＳＰＡは、ルーティング監視の機能を提供し、アプリケーションのルーティングが切り替えられる場合、ライフサイクルに基づいて対応するサブアプリケーションのフレームワークコードとビジネスコードをロードし、それによって異なるフレームワークとマルチレベルルーティングにおけるアクティブ化を実行する能力を実現する。ロード関数を公開することにより、ルーティングの切り替えをシミュレートし、メインアプリケーションによる能動的な呼び出し、アクティブ化の能力を実現する。

サブアプリケーション実行モジュールは、ＪＳサンドボックスとＣＳＳサンドボックス（非伝統的なＩｆｒａｍｅモードが存在する）を含み、サブアプリケーション実行モジュールは、サブアプリケーションロードモジュールによってプルされたｊｓリソースをロードするという役割を果たす。

ＪＳサンドボックスの設計は、図９に示され、ｗｉｔｈ関数９０１とプロキシ９０２を使用して基本的なｊｓサンドボックスを実現し、本出願の実施例では、Ｐｒｏｘｙプロキシとスナップショットプロキシモードを実現することができ、スナップショットプロキシモードはＥＳ６Ｐｒｏｘｙをサポートしていない環境をコンパチブルする。図９に示すように、アプリケーションローダーのリソースローダーによって解析されたサブアプリケーションの実際コード９０３を、プロキシサンドボックスに入れることによって実行する。また、一般的なスコープからのエスケープについては、スタック検査とキーワード検査により防止され、それによって、サブアプリケーションが制御可能である前提で基本的な安全を実現する。

本出願の実施例では、次の３つのＣＳＳサンドボックス手段が提供される。

１つ目は、サブアプリケーションのｗｅｂｐａｃｋでのパッケージングによるプレフィックスに基づく手段である。サブアプリケーションは、パッケージングツールに統一にアクセスし、各サブアプリケーションのスタイルに個別の命名空間を割り当てる必要がある。

２つ目は、サブアプリケーションの実行時のプレフィックスに基づく手段である。

幾つかのスタイルは、例えば＠ｋｅｙｆｒａｍｅｓ、＠ｆｏｎｔ－ｆａｃｅ、＠ｉｍｐｏｒｔなどをサポートしにくく、しかも動的にロードされる＜ｌｉｎｋ＞スタイルには特別な処理が必要であるため、サブアプリケーションの実行時に、サブアプリケーションのスタイルにプレフィックスを追加することで、スタイルの衝突を回避することができる。

３つ目は、ＳｈａｄｏｗＤｏｍに基づく手段である。ＳｈａｄｏｗＤｏｍは、ｓｈａｄｏｗ境界、イベント紛失、アクセス制御（ｓｈａｄｏｗＲｏｏｔ）などの問題を処理する必要がある。

本出願の実施例によって提供されるマイクロフロントエンドシステムは、ルーティング登録サービスを提供し、独立的にメンテナンス・実行するＮｏｄｅサービスとしては、優れた容量拡張及びディザスタリカバリ能力を提供し、マイクロフロントエンドのサブアプリケーションの登録及びルーティングのロードをメンテナンスする。Ｓｉｎｇｌｅ－ＳＰＡに基づいて、マルチフレームワークでのサブアプリケーション実行能力を提供し、カスタマイズされたロードソリューションに基づいて、メインアプリケーションがルーティングの登録に依存することなく、サブアプリケーションを能動的にレンダリングする能力を提供する。また、通信メカニズムでＰｒｏｐｓ伝送、Ｃｕｓｔｏｍ Ｅｖｅｎｔ、ＰｏｓｔＭｅｓｓａｇｅを含む３つの通信サポートを提供し、Ｐｒｏｐｓ伝送は、応答式の双方向データ伝送能力を提供することができ、Ｃｕｓｔｏｍ Ｅｖｅｎｔは、コンポーネントに基づいてイベントの配布と登録を定義することができ、それによってアプリケーションが多くなる場合の無関係なイベントの影響を回避することができ、ＰｏｓｔＭｅｓｓａｇｅは、グローバルなイベントの送受信を提供し、ブロードキャストクラスのメッセージ通知を実現するように構成され、各通信次元に応答する実現ソリューションがあり、手段が豊富で、副作用が小さい。該マイクロフロントエンドシステムは、クロスドメインをサポートするために、インターフェースリソースを含むサーバ側のＣＯＲＳソリューションを提供し、プライベートの静的リソース、ＣＤＮ静的リソースは、クロスドメインをサポートするために、ＣＯＲＳソリューションを提供し、ＷｅｂＷｏｒｋｅｒは、ドメインを跨いでｗｏｒｋｅｒを呼び出す問題を解決するために、インライン構築ローダーとインライン実行ローダーを提供し、サブアプリケーションのロード及び呼び出しを加速するために、キャッシュ、プリロード、ＷｅｂＷｏｒｋｅｒなどの手段をさらに提供する。実行時にサブアプリケーションをロードするソリューションをさらに提供し、実行時にサブアプリケーションのレンダリングするコンテンツ、インタラクションのロジックを変更し、より高い自由性を提供することができる。

本出願の実施例は、コンピュータープログラム製品又はコンピュータープログラムを提供し、該コンピュータープログラム製品又はコンピュータープログラムはコンピューター命令を含み、該コンピューター命令はコンピューター可読記憶媒体に記憶される。コンピューター機器のプロセッサは、コンピューター可読記憶媒体から該コンピューター命令を読み取り、プロセッサは該コンピューター命令を実行して、該コンピューター機器に、本出願の実施例の上述のマイクロフロントエンドシステムに基づくサブアプリケーションロード方法を実行させる。

本出願の実施例は、実行可能な命令を記憶する記憶媒体を提供し、実行可能な命令が記憶され、実行可能な命令がプロセッサによって実行される場合、プロセッサに、本出願の実施例で提供されるサブアプリケーションロード方法、例えば、図３、図４及び図５に示すサブアプリケーションロード方法を実行させる。

いくつかの実施例では、記憶媒体は、コンピューター可読記憶媒体、例えば、強誘電体メモリ（ＦＲＡＭ：Ｆｅｒｒｏｍａｇｎｅｔｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、読み取り専用メモリ（ＲＯＭ：Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、プログラマブル読み取り専用メモリ（ＰＲＯＭ：Ｐｒｏｇｒａｍｍａｂｌｅ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、消去可能なプログラマブル読み取り専用メモリ（ＥＰＲＯＭ：Ｅｒａｓａｂｌｅ Ｐｒｏｇｒａｍｍａｂｌｅ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、電気的消去可能なプログラマブル読み取り専用メモリ（ＥＥＰＲＯＭ：Ｅｌｅｃｔｒｉｃａｌｌｙ Ｅｒａｓａｂｌｅ Ｐｒｏｇｒａｍｍａｂｌｅ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、フラッシュメモリ、磁気表面メモリ、光ディスク、又はコンパクトディスク読み取り専用メモリ（ＣＤ－ＲＯＭ：Ｃｏｍｐａｃｔ Ｄｉｓｋ－Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）などのメモリであってもよく、上述のメモリの１つ又は任意の組み合わせを含む各種の機器であってもよい。

いくつかの実施例では、実行可能な命令は、プログラム、ソフトウェア、ソフトウェアモジュール、スクリプト又はコードの形式を採用することができ、任意の形式のプログラミング言語（コンパイル言語又はインタープリター言語、又は宣言型言語又は手続き型言語を含む）で書かれ、任意の形式で構成することができ、独立したプログラムとして構成されるか、又はモジュール、コンポーネント、サブルーチン、又は計算環境で使用するのに適した他のユニットとして構成されることを含む。

例として、実行可能な命令は、ファイルシステム内のファイルに対応することができるが、これに限らなく、他のプログラム又はデータを保存するファイルの一部に記憶されてもよく、例えば、ハイパーテキストマークアップ言語（ＨＴＭＬ：Ｈｙｐｅｒ Ｔｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）ドキュメントの１つ又は複数のスクリプトに記憶され、係るプログラムに専用に構成された単一のファイルに記憶されるか、又は、複数の共同ファイル（例えば、1つ又は複数のモジュール、サブルーチン、又はコード部分を記憶するファイル）に記憶される。例として、実行可能な命令は、１つの計算機器上で実行されるか、又は１つのサイトに位置する複数の計算機器上で実行されるか、又は、複数のサイトに分散され、通信ネットワークによって相互接続された複数の計算機器上で実行されるように構成され得る。

上記の説明は、本出願の実施例だけであり、本出願の保護範囲を限定するように構成されていない。本出願の精神及び範囲内で行われるいかなる修正、同等の置換及び改良は、いずれも本出願の保護範囲に含まれる。

１００ マイクロフロントエンドシステム
１０１ ルーティング登録サービス
１０２ コマンドラインツール
１０３ マイクロフロントエンド実行フレームワーク
１０３１ 基礎機能ライブラリモジュール
１０３２ 通信モジュール
１０３３ 統一ルーティングモジュール
１０３４ サブアプリケーションロードモジュール
１０３５ サブアプリケーション実行モジュール
１０３６ データ管理モジュール
１０３７ 性能監視モジュール
１０３８ エラー処理モジュール

Claims (19)

1. マイクロフロントエンドシステムであって、
   ルーティング登録サービス、コマンドラインツール及びマイクロフロントエンド実行フレームワークを含み、
   前記ルーティング登録サービスは、独立的にメンテナンス・実行するノードＮｏｄｅバックエンドサービスであり、メインアプリケーションのマイクロフロントエンド実行フレームワークに、サブアプリケーションのルーティング情報、前記サブアプリケーションのロード方式及び前記サブアプリケーションのデプロイメント情報を提供するように構成され、
   前記コマンドラインツールは、コマンドラインによりサブアプリケーション新規作成機能、サブアプリケーションアクセス機能、サービス登録機能を提供するように構成され、
   前記マイクロフロントエンド実行フレームワークは、前記メインアプリケーションで実行されるフレームワークであり、取得されたネットワーク要求に基づいて前記サブアプリケーションをロードして実行し、マルチフレームワークでのサブアプリケーション実行能力を提供するように構成される、マイクロフロントエンドシステム。
2. 前記マイクロフロントエンドシステムは、さらに、
   前記ルーティング登録サービスに対応するフロントエンドインターフェースを含み、前記フロントエンドインターフェースは、サブアプリケーション登録に設定する必要があるサブアプリケーション登録情報を取得し、前記サブアプリケーション登録情報を前記ルーティング登録サービスに送信するように構成され、前記サブアプリケーション登録情報は、サブアプリケーションフレームワーク、サブアプリケーションルーティングモード及びサブアプリケーションロードモードを含み、
   前記ルーティング登録サービスは、さらに、前記サブアプリケーション登録情報を受信し、前記サブアプリケーション登録情報に基づいて前記サブアプリケーションを登録するように構成される、ことを特徴とする
   請求項１に記載のマイクロフロントエンドシステム。
3. 前記コマンドラインツールは、さらに、サブアプリケーション新規作成コマンドを受信し、前記サブアプリケーションのルーティング情報、前記サブアプリケーションのリソース情報及びサブアプリケーションテンプレート情報を取得するように構成され、
   前記コマンドラインツールは、さらに、前記サブアプリケーションテンプレート情報に基づいてサブアプリケーションテンプレートを生成し、前記ルーティング登録サービスにサブアプリケーション新規作成要求を送信するように構成され、前記サブアプリケーション新規作成要求に前記ルーティング情報及び前記リソース情報が含まれ、
   前記コマンドラインツールは、さらに、サブアプリケーションデプロイメント要求をデプロイメントサーバに送信するように構成され、前記サブアプリケーションデプロイメント要求は、前記デプロイメントサーバが前記サブアプリケーションデプロイメント要求におけるサブアプリケーションリソースアドレスに基づいてリソースのデプロイメントを行うことをトリガーするために使用される、ことを特徴とする
   請求項１に記載のマイクロフロントエンドシステム。
4. 前記コマンドラインツールは、さらに、サブアプリケーションアクセスコマンドを受信し、前記サブアプリケーションのルーティング情報及び前記サブアプリケーションのリソース情報を取得するように構成され、
   前記コマンドラインツールは、さらに、サブアプリケーションアクセス要求を前記ルーティング登録サービスに送信するように構成され、前記サブアプリケーションアクセス要求に、前記サブアプリケーションのルーティング情報及びリソース情報が含まれ、
   前記ルーティング登録サービスは、さらに、前記サブアプリケーションアクセス要求を受信し、前記サブアプリケーションのルーティング情報及びリソース情報に基づいてサブアプリケーション登録を行うように構成される、ことを特徴とする
   請求項２に記載のマイクロフロントエンドシステム。
5. 前記マイクロフロントエンド実行フレームワークは、基礎機能ライブラリモジュール、通信モジュール、統一ルーティングモジュール、サブアプリケーションロードモジュール及びサブアプリケーション実行モジュールを含み、
   前記基礎機能ライブラリモジュールは、パブリックメソッド及びパブリックコンポーネントを提供し、グローバル変数及び関数の方式により、前記サブアプリケーションに使用される前記パブリックメソッド及び前記パブリックコンポーネントを前記サブアプリケーションに入れ込むように構成され、
   前記通信モジュールは、前記メインアプリケーションから前記サブアプリケーションへの、前記サブアプリケーションから前記サブアプリケーションへの、及び前記サブアプリケーションから前記メインアプリケーションへの通信メカニズムをサポートするように構成され、
   前記統一ルーティングモジュールは、ブラウザルーティング変更を監視するように構成され、
   前記サブアプリケーションロードモジュールは、前記ルーティング登録サービスからサブアプリケーションリソースアドレスを取得し、前記サブアプリケーションリソースアドレスに対応するリソースを取得してロードするように構成され、
   前記サブアプリケーション実行モジュールは、前記サブアプリケーションリソースアドレスに対応するリソースを実行し、サブアプリケーションのページをレンダリングするように構成される、ことを特徴とする
   請求項１に記載のマイクロフロントエンドシステム。
6. 前記メインアプリケーションからサブアプリケーションへの通信メカニズムは、プロップＰｒｏｐｓ伝送とカスタムイベントＣｕｓｔｏｍ Ｅｖｅｎｔ伝送を含み、前記サブアプリケーションからサブアプリケーションへの通信メカニズムは、メッセージ送信ＰｏｓｔＭｅｓｓａｇｅ伝送を含み、前記サブアプリケーションからメインアプリケーションへの通信メカニズムは、Ｃｕｓｔｏｍ Ｅｖｅｎｔ伝送を含み、
   前記サブアプリケーションロードモジュールが前記サブアプリケーションをロードするモードは、ハイパーテキストマークアップ言語ＨＴＭＬエンティティモード、スクリプト言語ＪＳエンティティモード及びページを嵌め込むＩｆｒａｍｅモードを含む、ことを特徴とする
   請求項５に記載のマイクロフロントエンドシステム。
7. 前記マイクロフロントエンド実行フレームワークは、データ管理モジュール、性能監視モジュール及びエラー処理モジュールをさらに含み、
   前記データ管理モジュールは、Ｐｒｏｐｓ伝送メカニズムによって提供されるデータにより、データ双方向バインディング機能を実現するように構成され、
   前記性能監視モジュールは、サブアプリケーションのロード時間長及び実行時間長を監視するように構成され、
   前記エラー処理モジュールは、ロード及び実行中におけるサブアプリケーションのエラー情報を監視及び処理するように構成される、ことを特徴とする
   請求項５に記載のマイクロフロントエンドシステム。
8. 前記サブアプリケーションロードモジュールは、さらに、取得した前記サブアプリケーションのビジネスコードを解析し、解析後のビジネスコードを前記サブアプリケーション実行モジュールに伝送するように構成され、
   前記サブアプリケーション実行モジュールは、実行環境サンドボックスを含み、前記解析後のビジネスコードが前記実行環境サンドボックスで実行される、ことを特徴とする
   請求項５に記載のマイクロフロントエンドシステム。
9. 前記実行環境サンドボックスは、ＪＳサンドボックス、積層スタイルシートＣＳＳサンドボックス及びバックグラウンドスクリプトＷｅｂＷｏｒｋｅｒサンドボックスを含む、ことを特徴とする
   請求項８に記載のマイクロフロントエンドシステム。
10. 前記ＷｅｂＷｏｒｋｅｒサンドボックスは、ＷｅｂＷｏｒｋｅｒに割り当てられたスクリプトファイルをインラインで実行し、前記ＷｅｂＷｏｒｋｅｒのクロスドメインでの呼び出しを実行するように構成される、ことを特徴とする
    請求項９に記載のマイクロフロントエンドシステム。
11. 前記マイクロフロントエンドシステムは、クロスドメインリソース共有をサポートするサーバをさらに含む、ことを特徴とする
    請求項１乃至１０のいずれか一項に記載のマイクロフロントエンドシステム。
12. 電子機器が実行する、マイクロフロントエンドシステムに基づくサブアプリケーションロード方法であって、前記マイクロフロントエンドシステムは、ルーティング登録サービス、サブアプリケーションロードモジュール及びサブアプリケーション実行モジュールを含み、前記サブアプリケーションロード方法は、
    ネットワークアクセス要求を取得するステップであって、前記ネットワークアクセス要求に、アクセス対象ページのユニフォームリソースロケータ（ＵＲＬ）アドレスが含まれるステップと、
    前記ＵＲＬアドレスに基づいて、前記ルーティング登録サービスから、対応するルーティング情報をプルするステップと、
    前記ルーティング情報に基づいて、前記アクセス対象ページがサブアプリケーションのページであると決定した場合、前記サブアプリケーションロードモジュールは、前記ルーティング情報に基づいて前記ルーティング登録サービスから前記ルーティング情報に対応するサブアプリケーションリソースを取得するステップと、
    前記サブアプリケーションリソースをロードする必要がある場合、前記サブアプリケーションロードモジュールは、前記サブアプリケーションリソースをロードするステップと、
    前記サブアプリケーション実行モジュールは、前記サブアプリケーションリソースを実行し、サブアプリケーションのページをレンダリングするステップと、を含む、サブアプリケーションロード方法。
13. 前記サブアプリケーションロード方法は、さらに、
    前記サブアプリケーションリソースがプリロードされたか、又は開かれたかどうかを決定するステップと、
    前記サブアプリケーションリソースがプリロードされておらず、且つ開かれていない場合、前記サブアプリケーションリソースをロードする必要があると決定するステップと、を含む、ことを特徴とする
    請求項１２に記載のサブアプリケーションロード方法。
14. 前記サブアプリケーションロード方法は、さらに、
    サブアプリケーション登録に設定する必要があるサブアプリケーション登録情報を取得し、前記サブアプリケーション登録情報をルーティング登録サービスに送信するステップであって、前記サブアプリケーション登録情報は、サブアプリケーションフレームワーク、サブアプリケーションルーティングモード及びサブアプリケーションロードモードを含む、ステップと、
    前記ルーティング登録サービスにより前記サブアプリケーション登録情報を受信し、前記サブアプリケーション登録情報に基づいて前記サブアプリケーションを登録するステップと、を含む、ことを特徴とする
    請求項１２に記載のサブアプリケーションロード方法。
15. 前記サブアプリケーション登録に設定する必要があるサブアプリケーション登録情報を取得するステップは、
    前記ルーティング登録サービスに対応するフロントエンドインターフェースにより、サブアプリケーション登録に対する入力操作を取得するステップと、前記入力操作に基づいて前記サブアプリケーション登録情報を決定するステップ、
    又は、
    コマンドラインツールによりサブアプリケーション新規作成コマンドを受信し、前記サブアプリケーションのルーティング情報、前記サブアプリケーションのリソース情報及びサブアプリケーションテンプレート情報を取得するステップ、を含む、ことを特徴とする
    請求項１４に記載のサブアプリケーションロード方法。
16. 前記サブアプリケーションリソースをロードする必要がある場合、前記サブアプリケーションロードモジュールは、前記サブアプリケーションリソースをロードするステップは、
    前記サブアプリケーションリソースをロードする必要がある場合、前記サブアプリケーションのフレームワーク識別子及びリソースロードタイプを取得するステップと、
    前記リソースロードタイプに基づいて、前記フレームワーク識別子に対応するサブアプリケーションフレームワークで前記サブアプリケーションリソースをロードするステップと、を含む、ことを特徴とする
    請求項１２に記載のサブアプリケーションロード方法。
17. 前記サブアプリケーションロード方法は、さらに、
    前記ルーティング情報に基づいてアクセス対象ページがメインアプリケーションページであると決定した場合、ライフサイクルに基づいてメインアプリケーションに現在マウントされているサブアプリケーションを決定するステップと、
    前記現在マウントされているサブアプリケーションからレンダリングするべき目標サブアプリケーションを決定するステップと、
    公開されるロード関数と前記目標サブアプリケーションに基づいて、ルーティング切り替えをシミュレートし、前記目標サブアプリケーションのサブアプリケーションリソースとメインアプリケーションリソースを取得するステップと、
    前記サブアプリケーションリソースと前記メインアプリケーションリソースをロードして実行し、レンダリング済みの前記メインアプリケーションのページにサブアプリケーションをレンダリングするステップと、を含む、ことを特徴とする
    請求項１２乃至１６のいずれか一項に記載のサブアプリケーションロード方法。
18. 電子機器であって、メモリと、プロセッサとを含み、前記メモリはコンピュータープログラムを記憶し、前記プロセッサは、前記コンピュータープログラムにより、請求項１２至１７のいずれか一項に記載のマイクロフロントエンドシステムに基づくサブアプリケーションロード方法を実行する、電子機器。
19. プロセッサに、請求項１２至１７のいずれか一項に記載のマイクロフロントエンドシステムに基づくサブアプリケーションロード方法を実行させる、コンピュータープログラム。