iframeのマイクロフロント
ある会社では、CTOは、マイクロフロントはマイクロサービスと同等であり、iframeで提供する必要があるというバランスの取れた慎重な決定を下しました。
ちなみに、MicrosoftのOffice 360製品は、以前はトップメニューとサイドメニューに「<iframe />」を使用していました。現在、iframeはありません。
マイクロフロントの理由と前提条件
マイクロフロントエンドの主な利点の1つは、モノリスの機能をチームに分割すること、エンドツーエンドのテストをよりきめ細かく実行できること、およびソフトウェアを分割して販売することを容易にすることです（ボックス化されたソリューションの場合）。
利用可能なアプリケーションはすべてReactSPAです。これらには、Material UI、React Router v4、およびnpmモジュールとしてのembryoUIキット以外に共通点はありません。
一部のアプリケーションは、スタンドアロンバージョンと別のアプリケーションの一部の両方で使用および提供されます。
マイクロフロントは大きな機能ブロックに分割されました。
- アプリケーションヘッダー。アプリ間のルーティング
- ダッシュボードアプリケーション。メトリックとウィジェットを使用します。各ダッシュボードウィジェットは、対応するアプリケーションの一部である必要があります（iframeを介して接続されています）。
- アプリケーション自体。それらのいくつかはお互いの一部を含んでいます（しかし狂信と再帰はありません）
したがって、互いに独立して、異なるリリースサイクルが得られます。アプリケーションが内部APIに従っている限り。
問題＃0。マイクロフロントの不適切な分離
残念ながら、マイクロフロントは十分に深く考えられていません。例はオンラインストアです。購入ボタンとショッピングカートは多くの場所に散らばっていますが、それらはすべて1つのマイクロフロントです。 10種類の製品カードとして、および注文プロセス（請求書と住所）。これらはすべて、独自のリリースサイクルを持つ個別のマイクロフロントにすることができます。
実際には、アプリケーションは非常に大まかに分割されていることが判明しました。オンラインストアと同様に、これは1つのチームがカートとチェックアウトページを作成し、2番目のチームが残り（他のすべてのページのカートカウンターを含む）を行う場合です。同時に、全員が同じビジネスロジックを使用し、インターフェイスはUIキットまたはMaterial-UIライブラリのレベルで再利用されます。
機能的なアプリケーション（緑と紫でマーク）には多くの共通点があることが判明しました。これら2つのアプリケーションのビジネスロジックの重要な部分は、個別のマイクロフロントに分離して使用する必要がありました。実際、そのようなアプリケーションは2つありません。合計で、適切なレベルでロジックを再利用しない機能的なアプリケーションが約7つありました。
その結果、アプリケーションの再利用による時間の節約に失敗しました。機能の重複も高水準にとどまりました。拡張UIキットのより複雑なロジックを備えたiframeまたはコンポーネントなしでマイクロフロントエンドを使用すると、機能の重複の問題を解決できます。
問題＃1。プロセスオーケストレーションの欠如
マイクロサービスの組織について多くの質問が議論されました。それらがどのように相互に通信するか、どのプロトコルによって、マイクロフロント間の相互作用のプロセスの組織化がバックバーナーに置かれました。
すべてのCORSの問題を完全に中和するために、ルーティングを処理するnginxを配置することが決定されました。したがって、各マイクロフロントと各マイクロサービスには独自のアドレスがあります。たとえば 、次のようになります。開発モードでアプリケーションをテストする方法は不明です。各アプリケーションは異なるポートで提供されますか？
https://domain.zone/dashboard
https://domain.zone/header
https://domain.zone/app1
https://domain.zone/app2
https://domain.zone/api1
https://domain.zone/api2
ここで、 `http-proxy-middleware`パッケージが役に立ちます。これはCRAと組み合わせて構成できます。フロントエンド開発者の半分だけがそのようなセットアップをセットアップできたことが判明しました。もちろん、ここで誰のせいにすることもできませんが、そのような問題が発生しており、組織的に解決する必要があります。
機能、使用可能なメソッド、および内部APIの説明を含む、すべてのアプリケーションの明確なバージョン管理も必要です。したがって、次の問題はドキュメントです。
問題＃2。内部APIの欠如
アプリケーションが相互にうまく相互作用するには、ドキュメントが必要です。残念ながら、私たちの場合、マイクロサービスだけがドキュメントを持っています。そして、視線はマイクロフロントに落ちませんでした。
これは、分散したチームの場合、さらにはスタッフの交代がある場合でも、システムの非常に重要な部分です。
また、アプリケーション間の通信メカニズムを開発する必要があります。ここで、 `postMessage API`は、ほぼすべてのReactアプリケーション（Redux）に組み込まれている、別のAPIへの直接アクセスを支援します。メッセージバスではないものは何ですか？しかし、それについては後で詳しく説明します。
問題＃3。Iframeは十分な柔軟性がありません
`<iframe />`タグを使用しても問題はありません。これは、組み込みのメッセージバス（postMessage API）と広範なセキュリティのカスタマイズを備えた強力なツールです。
ただし、マイクロフロンテンドの場合、 `<iframe />`には多くの制限があります。それらの1つは、ページのいくつかの部分で1つのアプリケーションを再利用できないことです。
アプリケーションを再利用する
オンラインストアの例の場合、10個の購入ボタンは10個の `<iframe />`、つまり10個の実行中のReactアプリを作成します。これには十分なメモリがありません。これが、アプリケーションを機能ごとにチームに分割できない理由の1つです。
URLは状態管理として適切ではありません
私たちは皆、URLを介してアプリをルーティングすることに慣れています。これは、マイクロフロントを独立したユニットとして使用する場合にも便利です。たとえば、メインアプリケーションの一部がそれ自体で役立つほど一貫している場合です。もちろん、これはiframeアプローチのユニークな利点ではありませんが、実行するのは非常に簡単です。
これは、異なるURLを持つKDPVの紫色のアプリケーションがスタンドアロンアプリケーションとしてどのように機能するかの例です。
ただし、この場合、URL iframeインターフェイスを使用してマイクロフロントの状態を切り替えることは不可能であることが判明しました。履歴APIとその `pushStateの統合が不完全なため、マイクロフロントは最初からロードを開始します。 `とルータに反応-取得フルページのリフレッシュを。
「iframe」クリックハンドラーの外側
ドロップダウンメニューを作成するとします。上の図のように：ピンクのメニューから。また、空のスペースをクリックして閉じます。iframeの場合、ウィンドウオブジェクトが異なるためにアウトクリックが認識されないため、条件付きpostMessageAPIを使用する必要があります。または、拡大されたiframe要素の背景を全画面で透明にするハックを考え出します。
ちなみに、iframeのサイズを変更し、それに合わせて親アプリを調整することも、より面倒で複雑になります。
ボーナスの問題：不適切なCookieの使用
この問題はマイクロフロントに直接関係しているわけではありませんが、次のレベルの狂気につながります。
トークンだけでなく、アプリケーションの特定の部分に対する権利の完全なリストも承認Cookieに書き込むことが決定されました。これはすべてSHAによって暗号化されました-??? そしてbase64に変換されます。
その結果、Cookieのサイズがnodejs / nginxのデフォルト値である8KB（または、Google Chromeの1つのCookieレコードのサイズの場合は2KB）を超えたため、サーバー構成がより複雑になり（CRAを排出しないと、この設定で開始できなくなります）、また、この大きな暗号化されたデータセットを小さなCookie文字列に分割します。
つまり、「favicon.ico」を取得したり、使用可能なメニューセクションのリストを取得したりする場合でも、サーバーへのすべてのリクエストには、印象的なサイズの追加ヘッダーが装備されています。
結論。では、どのようにしてマイクロフロントと一緒に暮らすのでしょうか？
もちろん、最初に、マイクロフロントが必要かどうかを判断する必要がありますか？多くの場合、npmモジュールの形式で適切に構成および強化されたUIキットは、独立したリリースと同じ視覚スタイルの両方の問題を解決します。
- iframeは使用しないでください。作業を簡素化するのではなく、パフォーマンスの問題を追加するだけで、アプリケーションをマイクロフロントに分割する機能が大幅に制限されます。SPAのチャンクを特別に予約されたタグにレンダリングすることは、はるかに効率的なソリューションです。
- プロセスオーケストレーションを開発します：生産と開発の両方で。すべての開発者が、既製のブロックからインターフェイスをリベットするために雇われたときに、ルーティングとプロキシの関連業界に飛び込みたいとは限りません。
- アプリケーション間のメッセージバスを開発します。これは、単一のグローバルスペースであるウィンドウオブジェクトの場合にはるかに簡単です。
- アプリケーションの相互作用、およびそれらの起動と構成のためのインターフェースに関するドキュメントを作成します。