web-dev-qa-db-ja.com

マイクロフロントエンドアーキテクチャのアドバイス

1つの単一ページアプリケーションの下に表示したいWebアプリケーションがいくつかあります。使用するマイクロフロントエンドアーキテクチャ/フレームワークを探しています。ご覧のとおり、これらは実装のオプションです。

  1. シングルスパオープンソースフレームワークの使用： https://github.com/CanopyTax/single-spa
  2. ホスティングアプリケーション（シェル）であるIframes（Friendly Iframes）を使用し、現在のURLに従って各アプリケーションを読み込みます。
  3. 独自のJavascriptフレームワークを作成する
  4. その他？

現在の状態は、他の子アプリケーションを内部のサードパーティパッケージとして使用するモノリスFEアプリケーションです。ホスティングアプリケーションがすべての製品を一緒に構築しており、実際に分離されているものはないため、このアプローチはスケーラブルではありません。

私たちの要件は、マイクロフロントエンドの通常の要件です。1.独立した開発-各チームは、独自のフレームワークを選択し、他の製品に関係なく製品を構築できます。

  1. 独立した展開-各アプリケーションは、ダウンタイムなしで、他のアプリケーションに干渉することなく、運用環境でアップグレードできます。

  2. 共有コンポーネント-私たちはアプリケーションでAngular4を使用しており、同様のルックアンドフィールのためにすべての製品間で共有する必要がある独自のサードパーティライブラリ（共有コンポーネントとロジック）をすでに記述しています。

  3. 他のアプリケーションを気にすることなく、各アプリケーションのフレームワーク（Angular、RXjs、TypeScriptなど、さらには独自のコンポーネントライブラリ用）をアップグレードできるようにしたいと考えています。

シングルスパフレームワークを使用しようとしましたが、いくつかの問題があり、現在、これが適切なアプローチであるかどうか、または別のアプローチを試す必要があるかどうかを自分で考えていることがわかりました。

シングルスパを使用している問題は次のとおりです。1.アセットのロードに問題があります。 （アセットファイルはホスティングアプリケーションのルートフォルダーにある必要があり、別のアプリケーションに切り替えるとアセットの競合が発生します）。 2.すべてのアプリケーションのグローバルスタイリングを処理する方法がまだわかりません（スタイリングにはsassを使用し、各アプリケーションのローカルスタイルと一緒に準拠する必要があります）3.アップグレードangular framework （または他のすべてのフレームワーク）は、1つのアプリケーションでは不可能であり、すべてまたは何でもありません（angularのインスタンスが1つあるためです）。

（Friendly Iframeを使用した）Iframeソリューションについて考えるとき、すべての子アプリケーション間の完全な分離を視覚化し、これが私たちにとってより適切なアプローチであると信じがちです。

IFrameを使用する際の落とし穴はありますか？

ありがとう、ダニエル

angulariframewebfrontend
18
Hasholef

質問はやや広いため、状況（ターゲットグループ？、モバイル？、KPIは何ですか？（パフォーマンス、初期ロード、開発コスト、再利用性、...）

Iframeは「完全な」分離（コード+スタイル）に適していますが、他のアプローチではこれが得られませんが、そのためlotの欠点があります。

  • iframe間でデータを共有するには、外部SPAと内部SPAのオーケストレーションが必要です。これには、追加のセキュリティ対策の設定が含まれます（各SPAが公開されているため）。
  • 内側のSPAを外側のSPAでスタイリングすると、同じドメインにあり、追加のJSコードが必要な場合にのみ機能します
  • 内側のSPAが外側のSPAと同じドメインにある場合、Cookieの共有のみが機能します
  • パフォーマンスに関しては、各Iframeがすべてを単独でロードする必要があります。アセットやライブラリなどの再利用は非常に難しく、各SPAのツールをいじる必要があります。

通常、すべてが制御下にある場合実際のマイクロフロントエンドアプローチを使用するのが、Iframeよりも優れたソリューションです。

3
Christian Ulbrich

フロントエンドのマイクロサービスの可能なアーキテクチャソリューションのトピックに2¢を追加したいと思います。

  1. OpenTableで使用されるOpenComponents – https://github.com/opentable/oc
  2. Zalandoによるモザイク– https://www.mosaic9.org/

あなたがそれらが役立つことを願っています。

3
sveg

PuzzleJs を試してみてください。ゲートウェイとストアフロントの両方のマイクロフロントエンドアーキテクチャに対するフレームワークソリューションになるように設計されています。高トラフィックのeコマースWebサイトの作成に使用されています。ぜひチェックしてみてください。

実際には、ほとんどすべての要件をカバーしています。

  • 独立した展開
  • 独立したソースコード
  • 独立したテクノロジー

また、iframeソリューションについては、CORSや他のiframeとの通信などの管理が難しくなる可能性があります。

しかし、マイクロフロントエンドソリューションはまだ完璧ではありません。深く掘り下げると、多くの複雑さが伴います。

一部のアセットはグローバルスコープで同じ変数を宣言しようとし、場合によってはエラーの原因となる異なるバージョンを持っています。したがって、チームは互いに完全に独立しているわけではありません。

ロギングとモニタリングは非常に困難になります。 New Relicのようなツールは役に立ちますが、それだけでは十分ではありません。カスタム監視およびエラー報告ツールを実装する必要があります。

アプリケーションをドッキングし、自動スケーリングに対応させることは非常に重要です。このアーキテクチャでは、4つのゲートウェイとストアフロントがある場合、注意が必要です。

マイクロフロントエンドアーキテクチャの実装にかかる初期コストは非常に高くなります。時間と開発者のリソースを慎重に検討する必要があります

パフォーマンスが最も重要です。複数のチームがそれらを使用しているため、reactまたは他のライブラリーを複数回ダウンロードしたくありません。 DllPluginn を実装して、重複するコードを削除する必要があります。そして、それはすべてを難しくします。

他にも覚えられない問題がたくさんあります。同じストアフロントプロジェクトで作業している開発者が50人を超えていない場合、マイクロフロントエンドはやりすぎです。

1
Ahmet Can Güven

this thread に対する私の答えは、参考になります。ただし、さらに明確にするために

  1. メインアプリケーションがwww.example.comにデプロイされている場合、各サブアプリケーションはインポートを強制することによってグローバルスタイルを継承する必要があります。つまり、
    @import url('https://www.example.com/path/to/global/style.css');
  2. Webコンポーネントの場合、個々のサブアプリケーションのスタイル設定は転送できません。同様に、ベースアプリケーションからスタイルを継承するには、上記のように強制する必要があります。
  3. 各サブアプリケーションは個別に構築できるため、言語に依存しません。 1つのアプリがVueを使用することを選択し、別のアプリがPolymerを使用することを選択する場合があります。
  4. Webコンポーネントの使用は、軽量で取り付けられるように設計されていることを除いて、iframeの使用と似ています。

それが役に立てば幸い

0
amustapha

各アプリケーションからWebコンポーネントを公開し、それらをメインSPAで集約/使用できます。 Webコンポーネントはすべてのブラウザーでサポートされており、主要なすべてのSAPファームワーク（angular、ember、react、vueなど）はwebcomponentをサポートしています。これにより、特定のSPAフレームワークにバインドされず、コンポーネントをどこにでも再配置できます。

0
Manmay

現在、シングルスパフレームワークでまったく同じことを行っています。そして、私たちはあなたと同じ結論に達しました。少なくとも子アプリにバンドルする方法がわからなかったため、子アプリの翻訳が1つの大きな問題でした。スタイルのような他のアセットも問題です。

フレームワークはマイクロフロントエンドスタイルで使用するように設計されていないため、私の提案は angular elements を待つことです。

0
Antti Väyrynen

IFrameの代わりにShadowDom v1.1を見ることができます。私は最近、この手法を使用してバンキングアプリを処理および配置し、親アプリ（jspサーバー側テンプレートを使用したステートフルアプリケーション）のスタイルを分離していますが、これはスタイルの分離のみを提供します。

子アプリケーションごとに異なるコードベースを使用することをお勧めします。このようにして、それらを個別に開発し、異なるAngular=バージョンに移行して、個別にデプロイできます。共有コンポーネントと独自のサードパーティライブラリをnode_moduleとして公開し、各子アプリケーションにインポートできます。 （私はあなたがプライベート/内部のアーティファクトなリポジトリ設定を持っているべきだと思います）

子アプリ間の相互通信は、localStorate/sessionStorageで実行できます。それらを共有サービスとしてさらにラップし、node_module依存関係として再度公開できます。

** セットアップ

yourcompany.com->親アプリ

yourcompany.com/app1.html->子アプリ1-bootstrapバンドルされたjsファイルとcss yourcompany.com/app2.phpを含むアプリケーション->子アプリ2-bootstrap jsファイルとcssがバンドルされたアプリケーションyourcompany.com/app3.jsp->子アプリ3-bootstrap jsファイルとcssがバンドルされたアプリケーション

**またはサブドメインを使用

yourcompany.com->親アプリ

app.yourcompany.com->子アプリ1

blog.yourcompany.com->子アプリ2

home.yourcompany.com->子アプリ3

0
Ethan Nguyen