知っておくべき11のマイクロフロントエンド開発ツール

サーバー側プログラミングの分野では、従来のモノリシックバックエンドをマイクロサービスに分解することで、これまでにない効率と、これまで利用できなかったスケーリングプロジェクトの機会を実現できました。それにもかかわらず、ほとんどのフロントエンドシステムは依然としてモノリスです。これにより、そのようなシステムでの作業を最適化することが困難になり、スケーラビリティが向上しなくなります。







マイクロフロントエンドの背後にある考え方は、Webプロジェクトのモノリシッククライアント側を管理しやすい小さな部分に分割することです。このアプローチでは、プロジェクトに関与する各チームには独自の作業領域があり、チームはプロジェクトの特定のフラグメントに対してのみ責任を負い、完全に独立してその開発に従事します。そのため、各チームは、他のチームとは独立して独自のコードベースを使用し、サブシステムの新しいバージョンをリリースし、継続的に少しずつ改善を加えています。このサブシステムと、他のチームが取り組んでいるアプリケーションの他のフラグメントとの統合は、APIを介して実行されます。この作業スキームでは、プロジェクトのインターフェイス部分は、連携して機能する独立したフラグメントから組み立てられます。



昨年5月のダン・アブラモフは次のように書いています彼のツイッターで、彼はマイクロフロントを理解していないと述べた。彼は、彼らが解決すべき問題は、優れたコンポーネントモデルによってすでに解決されていると信じています。「たぶん、マイクロフロントは技術的な問題ではなく、組織的な問題の解決策ですか？たとえば、2つの開発チームがプロジェクトのインフラストラクチャを含め、何も合意できない場合、彼は振り返ります。



マイクロフロントエンド開発には多くのアプローチがあります。プロジェクトビルド中のコンポーネントのインテリジェントな統合から、特定のルーティングアプローチを使用してコード実行中に連携するようにアプリケーションのさまざまな部分を編成することまでです。この記事では、マイクロフロントエンドの開発を目的とした最も注目すべきツールを集めました。

1.ビットプラットフォーム

ビットプラットフォームを使用すると、独立したコンポーネントからフロントエンドを組み立てることができます。コンポーネントの設計と管理に役立ちます。これはおそらく私のリストで最も人気のあるソリューションであり、本番環境の開発に最適です。bit.devの



ホームページを見ると、独立したコンポーネントから組み立てられていることがわかります。これらのコンポーネントはさまざまなチームによって作成され、これらのコンポーネントの背後にさまざまなコードベースがあります。しかし、それらはすべて互いに統合されているため、最終的には全体的なプロジェクトインターフェイスを形成できます。





ホームページbit.devは、コンポーネント、ビットの助けを借りて編成されている作品を使用して作成



コマンドラインツールビット開発するために使用される一般的なソフトウェア、コンポーネントをベースにし- 。 Bitを使用すると、コンポーネントを作成し、それらからインターフェイスを組み立てることができます。



マイクロフロントエンドは通常、プロジェクトコードの実行中にインターフェイスを組み立てることとして理解されます。また、ビットプラットフォームは、プロジェクトのビルド中にフロントエンドを形成することを目的としています。これにより、このプラットフォームを使用するユーザーは、セキュリティと信頼性という形での「従来のモノリス」の便利な機能と、マイクロフロントエンドソリューションの利点（ソリューションのシンプルさとスケーラビリティ）の両方を利用できます。



Bitを使用すると、さまざまなチームが独自のコンポーネントを個別に作成および公開し、コンポーネントAPIレベルで他のチームとやり取りできます。これにより、Web開発を個別のモジュールからプロジェクトを構築するプロセスに変えることができます。コンポーネントベースの開発用



のツールに加えて、Bitプロジェクトは開発者にクラウドベースのプラットフォームを提供します。このプラットフォームを使用すると、コンポーネントで共同作業を行い、開発プロセスを効果的に管理し、拡張することができます。同時に、特定のプロジェクトの独自の部分での作業に関与するチームは、完全に独立したままです。



Bitは、プロジェクトの迅速な組み立てを整理することを目的とした、完全にコンポーネントに基づく独自のCI / CDプロセスを提供します。これは、さまざまなチームが、プロジェクトに悪影響を与えることを恐れることなく、開発するプロジェクトの部分に変更を加えることができることを意味します。他のチームを待ったり、プロジェクトのマスターブランチの変更を競ったりする必要はありません。開発者は、プロジェクトの占有されていない部分を混乱させることなく、継続的かつ安全にコンポーネントに変更を加えることができます。これらの変更は、これらのコンポーネントを使用するすべてのアプリケーションに適用されます。





コンポーネントベースの連続統合システムは、従来のシステムの50倍高速です。



その結果、開発プロセスは次の機能で強化されます。

• 互いに独立した個別の部分を持つ単純なコードベース。
• 自律チーム。
• コンパクトで明確に定義されたAPI。
• 完成したコンポーネントをリリースするための独立したプロセス。
• コンポーネントの継続的な段階的改善の可能性。

これは、プロジェクトに関する同様の作業組織の例です。



チームがコンポーネントベースの開発を行っており、マイクロフロントエンドテクノロジーを活用し、大規模なアプリケーションで作業するためのモジュラーアプローチを採用するソリューションを探している場合は、ビットプラットフォームを確認することをお勧めします。これがまさにあなたが必要としているものである可能性は十分にあります。

2.Webpack5およびモジュールフェデレーションアーキテクチャ

JavaScriptアーキテクチャモジュールフェデレーション（MF）は、ZachJacksonによって提案されました。彼はまた、このアーキテクチャを実装するためのWebpackプラグインの作成を開始しました。 Webpackチームの努力のおかげで、このプラグインはWebpack 5に登場し、現在ベータ版です。



MFの背後にある考え方は、複数の個別のアセンブリが単一のアプリケーションを形成する必要があるということです。これらの個別のアセンブリは相互に依存関係があってはならず、個別に開発および展開できます。これはマイクロフロントスタイルのスキームです。



MFを使用すると、JavaScriptアプリケーションは、実行時に他のアプリケーションからコードを動的にインポートできます。モジュールは、その機能をエクスポートするファイルを作成します。これは、他のアプリケーションがロードできるコードへのエントリポイントです。これは、それに応じてwebpackを構成することによって行われます。



このアプローチは、とりわけ、依存関係の共有を整理することにより、コードの依存関係の問題とバンドルサイズの増大の問題を解決します。たとえば、Reactコンポーネントをロードした場合、すでにReactをインポートしたアプリケーションは、ライブラリコードを再インポートしません。システムはすでにインポートされたReactコードを使用し、コンポーネントコードのみをインポートします。最後に、React.lazyとReact.suspenseを使用して、インポートされたコードが何らかの理由で失敗した場合のフォールバックを提供できます。これにより、プロジェクトが依存するアセンブリが機能していない場合でも、正しいユーザーエクスペリエンスを確保できます。



モジュールフェデレーションアーキテクチャは、マイクロフロントエンド開発に非常に興味深い可能性をもたらします。このアーキテクチャの詳細とその使用例については、こちらをご覧ください。

3.シングルスパプロジェクト

シングルスパ プロジェクトの作成者は、これを「フロントエンド開発でマイクロサービスを使用するためのJavaScriptフレームワーク」と定義しています。その本質を簡単に説明すると、プロジェクトを構成する個々のアプリケーションに適用される、あるエンティティのライフサイクルのアイデアを実装していると言えます。すべてのアプリケーションはルーティングイベントに応答でき、DOMにデプロイ、マウント、およびDOMからアンマウントする方法を知っている必要があります。通常のSPA（シングルページアプリケーション）とシングルスパで得られるものの主な違いは、シングルスパアプリケーションはプロジェクトの一部である他のアプリケーションと共存できなければならないということです。ただし、これらのアプリケーションには独自のHTMLページがありません。



その結果、プロジェクトコードの実行中に相互に統合する必要がある、同じページで異なるフレームワークまたはライブラリを使用する必要がある場合は、シングルスパを確認する必要があることがわかりました。これは、プロジェクトに関する基本的な情報を提供するビデオです。いくつかの例はここにあります。

4.SystemJSモジュールローダー

SystemJS モジュールローダーはマイクロフロントエンド開発のフレームワークではありませんが、このプロジェクトは、マイクロフロントエンドアーキテクチャを実装するための鍵となる独立モジュールのクロスブラウザー管理の問題を解決します（このアプローチは実際にはシングルスパでも使用されます）。



SystemJSは、JSモジュールオーケストレーターと考えることができます。標準のブラウザメカニズムに依存することなく、動的インポートやインポートマップなど、このようなモジュールのさまざまな機能を使用できます。そして、これらすべてが、ブラウザの組み込み機能によって提供されるものに近いレベルのパフォーマンスを備えています。 SystemJSの興味深い機能の中には、古いブラウザのポリフィルの存在、名前を使用したモジュールのインポート（モジュール名とそれらへのパスの照合による）、1つのリクエストで複数のモジュールのロード（APIを使用して複数のモジュールを単一のファイルとして表す）があります。



SystemJSでは、「モジュールレジストリ」を操作することもできるため、開発者は、特定の時点でブラウザで使用できるモジュールを知ることができます。ここに SystemJSチュートリアル入門。

5.ピラールフレームワーク

Piral フレームワークは、マイクロフロントエンドテクノロジを使用したポータルアプリケーションの開発を容易にするように設計されています。Piralを使用すると、マイクロフロントエンドアーキテクチャを使用し、piletと呼ばれる独立したモジュールを使用して、実行時に拡張できるモジュラーフロントエンドアプリケーションを作成できます。チケットは、コードやその他の必要なリソースなど、システムの他の部分とは独立して開発できます。これは、Piralの操作方法を示すビデオです。



Piralを使用する場合は、コードエディター、ターミナル、ブラウザー、およびNode.jsが必要です。Piralインスタンス（アプリケーションラッパー）とパイル（モジュール）は、ローカル開発マシンのエミュレーターで実行およびデバッグできます。





Piralでの作業

6.コンポーネントプロジェクトを開く

Open Components プロジェクトは、「サーバーレステクノロジーをフロントエンドの世界にもたらす」ことを目的としています。より正確には、このプロジェクトは、マイクロフロントエンドを開発するためのフレームワークとして作成されました。これにより、開発者は必要なすべてを提供し、コンポーネントを操作するためのツール、コンポーネントレジストリ、テンプレート、さらにはコマンドラインツールを含むエコシステムを作成します。 Open Componentsプロジェクトには、次の2つの部分があります。

• components () — , , , , HTML, JavaScript CSS. , , - , Node.js- , . HTML-, -.
• consumers () — - (, -, , ), - -.

7. Qiankun

Qiankun プロジェクトは、「シングルスパに基づくマイクロフロントエンドの実装ですが、本番環境で使用する準備ができています」と説明されています。このプロジェクトは、小さなサブシステム（サブアプリケーション）から大きなアプリケーションを組み立てることに関連するいくつかの基本的な問題を解決することを目的としています。これらのタスクには、静的リソースの公開、サブシステムの結合、開発および展開中のサブシステムの相互の独立性の確保、コード実行中のサブシステムの分離の確保、依存関係の処理、ソリューションの高性能の確保が含まれます。





Qiankunプロジェクト

8.ルイージフレームワーク

Luigiは、マイクロフロントエンド開発用のビジネスに焦点を合わせたJavaScriptフレームワークであり、ローカルコンポーネントと外部コンポーネントを使用するユーザーインターフェイスを作成できます。Luigiは、特定のフレームワークやライブラリから独立したWebアプリケーション開発フレームワークです。このフレームワークは、アプリケーションの個々の部分が連携することを保証する手段を開発者に提供します。





Luigi Luigi



フレームワークは、2つのサブシステムで構成されています。これは、メインのアプリケーションおよびクライアントライブラリです。それらの間の相互作用は、postMessageAPIに基づいています。



これがLuigiを試すことができるサンドボックスです。そして、ここでは、プロジェクトのリポジトリがあります。ちなみに、SAPはそれに取り組んでいます。

9.FrintJSフレームワーク

FrintJSは、「スケーラブルなリアクティブアプリケーションを開発するためのモジュラーJavaScriptフレームワーク」です。これにより、さまざまなバンドラーによって構築されたアプリケーションをロードし、アプリケーションの構造化を支援し、ルーティングや依存関係の処理などのメカニズムを適切に機能させ続けることができます。このフレームワークは、React（このライブラリでの作業は十分に文書化され、テストされています）に加えて、追加のパッケージを通じてReactNativeとVueをサポートします。





FrintJS



→ここでFrintJSインタラクティブなサンドボックスは、

10.モザイク9

Mosaicは、マイクロサービスアーキテクチャを使用して構築された大規模なWebサイトを編成するときに、コンポーネントがどのように相互作用するかを定義する仕様によって統合されたサービスとライブラリのセットです。Mosaicは、いわゆる「フラグメント」を使用します。フラグメントは、個別のサービスによって維持され、実行時にテンプレートで指定された順序に従って結合されます。





Mosaic Architecture Mosaic



プロジェクトは、さまざまな問題の解決を目的としたさまざまなパッケージで表されます。その中には、ルーティング、ページレイアウトの形成、テンプレートの保存、インターフェイスの表示などがあります。

11.フレームワークPuzzleJS

PuzzleJSは、「スケーラブルで高速なWebサイトを開発するためのマイクロフロントエンドフレームワーク」です。これにより、相互に通信する「ゲートウェイ」および「インターフェース」（ストアフロント）と呼ばれるプロジェクトを作成できます。 PuzzleJSのクリエイターがフェイスブックから、microfrontエンドアーキテクチャの観点から、インスピレーションを取ったBigPipeのプロジェクト。





PuzzleJS



PuzzleJSを使用すると、構成ファイルを使用して相互作用をカスタマイズすることにより、独立した「ポータル」と「インターフェース」を作成できます。これにより、コンパイル時にHTMLテンプレートをJavaScript関数に変換できます。この操作は、データロード要求とは無関係です。その結果、この関数は要求に応じてデータの転送を非常に迅速に開始し、最初のバイトまでの時間などのWebページのパフォーマンスインジケーターを改善します。このフレームワークは、サーバー側でマテリアルのレンダリングを使用しているため、SEOの観点から優れています。さらに、ページの特定のフラグメントの操作に必要なAPIが要求への応答を停止した場合でも、他のフラグメントの作業が中断されることはありません。これは、PuzzleJSを使用した実際の例です。

結果

マイクロフロントエンド開発に使用できる他のフレームワークには、Podiumが含まれます。



ご覧のとおり、マイクロフロントエンドアーキテクチャに基づいてプロジェクトを作成する場合は、間違いなく多くの選択肢があります。



マイクロフロントについてどう思いますか？