マイクロフロントエンドパターン12 . 12:サーバ側構成
8149 ワード
サーバー側の構成は、名前が示すように、サーバー側でフラグメントをアセンブルするパターンです.
私が知っているアーキテクチャのいくつかは、ここにあります.
レイアウトサーバー+フラグメントサーバーは、単純なサーバー側の構成です.
ここのフラグメントサーバは、各マイクロフロントエンドチームによってフラグメントを返すサーバを意味し、レイアウトサーバはRails、PHP、Nodeなどのサーバー側アプリケーションです.フラグメントをアセンブルし、最後のHTML、CSS、およびJSを返すJSなど.
まず、ノードを考えましょう.JSレイアウトサーバ.
たとえば、2つのフラグメントサーバーがある場合、1つの露出コンポーネントと他の露出Vueコンポーネントを公開すると、レイアウトサーバーを解析し、それらを組み立てることができます.
したがって、既存のアプリケーションがノード以外の言語で書かれている場合はどうなりますか.JS ?実際、私はそれが多くの場合のパターンであると思います.
この場合、フレームワーク固有のフラグメントを処理するのは難しいので、HTML文字列を取り、フラグメントをアセンブルします.
これらのパターンはどちらも一見してうまく機能しているようです.
しかし、サーバからデータをコンポーネントに渡してSSRにしたい場合を考えてみましょう.この場合、フラグメントサーバー自体はデータを受け取ることができて、応答を返すことができるインタフェースを持っている必要があります.組織内には共通の理解が必要である.また、HTML文字列を返す場合は、コンポーネントをレンダリングし、データを受信した後に文字列に変換するように実装する必要があります.バージョン管理もうまく行うべきです.それは、このようにするために退屈になっていませんか?
レイアウトサーバー+フラグメントサーバーのパターンは簡単ですが、難易度は、要件の様々な対処しようとすると増加します.
レイアウトサーバ+フラグメントゲートウェイパターンは前の章で紹介されたゲートウェイ集約パターンに似ています.ここでのフラグメントゲートウェイの役割はゲートウェイ集約のAPIゲートウェイの役割と似ています.これは、複数のフラグメントへのアクセスの面倒を見て、レイアウトサーバーからの責任を分離し、フロントエンドからのインターフェイスを統一します.
例を見てみましょう.使用するアーキテクチャを次の図に示しますHypernova マイクロフロントエンド
ここで、レイアウトサーバはレールで構成され、フラグメントゲートウェイはノードで構成される.
1 )レイアウトサーバはサーバのデータを作成し、2 )ゲートウェイをフラグメント化するよう要求します.3 .フラグメントゲートウェイはデータをコンポーネントに渡し、最後にデータを返すHTMLを返します.1 .
フラグメントゲートウェイの役割は、レイアウトサーバの視点から抽象的な断片をAPIとして、SSR対応コンポーネントとして多種多様な断片を扱うためのゲートウェイになることです.さらに、フラグメントの側でどんなフレームワークを使用しても、フラグメントゲートウェイは既存のサーバアーキテクチャを変更せずにそれを扱うことができます2 .
以上がレイアウトサーバ+フラグメントゲートウェイの基本アーキテクチャです.OpenSponent、Podium、およびPuzzlejsを含むこのパターンでサーバー側の構成を行うことができるいくつかのフレームワークがあります.
ここでは、私は図書館と呼ばれるTailor .
テーラーは、レイアウトサーバー+フラグメントゲートウェイのパターンではなく、より洗練されたレイアウトサーバー、いくつかのユニークな機能を組み立てるフラグメントの面で.
テーラーでは、次のようにしてフラグメントを解決できます
フラグメントはストリームとして配送されるので、すべてのフラグメントが完了するのを待つ必要はありません.
SSRの断片は、JS/CSSの資産が必要なことを意味します.
テーラーは、リンクヘッダーの資産情報に対応します.これについての良いことは、あなたがロードするTailorに資産を伝えることができるということです.例えば、ハッシュのある資産に対して以下の応答を考慮する
レイアウトサーバー機能に焦点を当てたテーラーのライブラリを使用すると、TFTBとアセットマネージメントの最適化をしながら、マイクロフロントエンド消費者の一部に関する考慮事項を減らす.
ARAフレームワークは超新星に基づいており、マイクロフロントエンドを構築するためのCLIとモジュールのセットを提供します.その中でもサーバ側の構成はユニークである.
全体像は次の通りである.
詳細はこちらDoc , しかし、ここで私はちょうど概要を与える.
まず第一にAuthor's Medium は、ALAフレームワークを念頭に置いて、Stranglerパターンで設計されて示します.
例えば、モノリシックなアプリケーションビルトインRailsまたはLaravelを想像して、マイクロフロントエンドに適しているアーキテクチャに徐々にそれを再評価してください.
からMicrosoft Cloud Design Patterns )
以下、この仮定に基づいて説明する.
Novaプロキシは既存のアプリケーションの間にある逆プロキシで、ブラウザからリクエストを受け取り、HTMLをレンダリングします.
PHPサーバーはデータ層と通信し、HTMLを生成する際にプレースホルダは事前に埋め込まれ、NOVAプロキシに返されます.
Nova proxyは受信したHTMLを解析し、プレースホルダに埋め込まれたデータをNovaクラスタへのペイロードとして要求する.そのジョブは、プレースホルダを返されたフラグメントと置換する.この層は、例えばフォールバックやタイムアウトの処理にも責任がある.
Novaクラスタはこの章のフラグメントゲートウェイです.
NOVAクラスタは、NOVAプロキシからデータを複数の断片に一度に受け取ります.それが受け取るリクエストに基づいて、ノヴァクラスタは各々の断片を質問して、HTMLを生成して、それをNOVAプロキシに返します.
このアーキテクチャにより,既存のサーバはマイクロフロントエンドの意識を減らし,データを構築することに集中できる.また、責任を打破し、徐々に既存のレンダリングロジックをNOVAプロキシに動かし、バックエンド層をAPIとしてデカップリングすることもできます.
サーバー側の構成が達成できるものの一つはSSRです.別の利点は、ストリームで実装できることです.加えて、例えばフラグメントゲートウェイを提供することによって、顧客はもはやフラグメントにマルチプル要求をしなければならない.この種のパフォーマンスとSEO要件はいくつかのアプリケーションに必須であるかもしれません.その場合、サーバー側の構成は実装される必要があります.
また、既存のモノリシックサーバ側アプリケーションをマイクロサービスに分解する場合は、フロントエンドとバックエンドを緩く結合する必要があります.ALAフレームワークの例に示すように、サーバ側の構成は、レガシーモノリシックアプリケーションが徐々にリファクタリングされる場合を柔軟に扱うことができる.
あなたが気づいたかもしれないように、欠点の1つは、複雑さの増加です.フロントエンドだけではなくアーキテクチャを考慮する必要があり、サーバーリソースが存在するため、可用性とスケーラビリティを設計する必要があります.これらがどのように組織の開発効率を最終的に改善するかを意識することは常に重要です.
これは一般的にマイクロフロントエンドにも当てはまるが、まだ事実上の技術はない.既存のシステムと課題意識は組織と組織とが異なるので、各社がベストを発揮するような状況であり、その力を持つ企業はソフトウェアオープンソースを作る(したがって、この章で紹介されているライブラリのアーキテクチャは異なる).ライブラリやフレームワークのデザインコンセプトを理解する必要があります.
この章では、サーバー側の構成といくつかのライブラリのアーキテクチャを紹介します.私は、サーバー側の構成で、我々は現実世界の複雑な課題を考えながら便利になる柔軟なアーキテクチャを採用することができます信じています.
私は、これが同様にマイクロサービスの場合について議論されると確信します、しかし、組織はフレームワークを整列するかどうかの一般的な理解が必要であると思います.まず第一に、インタフェースとしてフレームワークagnosticを持つことは、より自然であることが分かる.各チームが独立して技術を選択できるという事実は、マイクロフロントエンドの本来の考えにも近い.しかし、実際には、さまざまなフレームワーク(結合層の複雑さ、バンドルサイズ、会社内のホイールを再発明)について考えることが多くあり、また、“ギルド”スタイルで情報を共有することができる利点があります.ユーザー側のユースケースについて考える必要があります.畝↩
私が知っているアーキテクチャのいくつかは、ここにあります.
レイアウトサーバ+フラグメントサーバー
レイアウトサーバー+フラグメントサーバーは、単純なサーバー側の構成です.
ここのフラグメントサーバは、各マイクロフロントエンドチームによってフラグメントを返すサーバを意味し、レイアウトサーバはRails、PHP、Nodeなどのサーバー側アプリケーションです.フラグメントをアセンブルし、最後のHTML、CSS、およびJSを返すJSなど.
まず、ノードを考えましょう.JSレイアウトサーバ.
たとえば、2つのフラグメントサーバーがある場合、1つの露出コンポーネントと他の露出Vueコンポーネントを公開すると、レイアウトサーバーを解析し、それらを組み立てることができます.
したがって、既存のアプリケーションがノード以外の言語で書かれている場合はどうなりますか.JS ?実際、私はそれが多くの場合のパターンであると思います.
この場合、フレームワーク固有のフラグメントを処理するのは難しいので、HTML文字列を取り、フラグメントをアセンブルします.
これらのパターンはどちらも一見してうまく機能しているようです.
しかし、サーバからデータをコンポーネントに渡してSSRにしたい場合を考えてみましょう.この場合、フラグメントサーバー自体はデータを受け取ることができて、応答を返すことができるインタフェースを持っている必要があります.組織内には共通の理解が必要である.また、HTML文字列を返す場合は、コンポーネントをレンダリングし、データを受信した後に文字列に変換するように実装する必要があります.バージョン管理もうまく行うべきです.それは、このようにするために退屈になっていませんか?
レイアウトサーバー+フラグメントサーバーのパターンは簡単ですが、難易度は、要件の様々な対処しようとすると増加します.
レイアウトゲートウェイ
レイアウトサーバ+フラグメントゲートウェイパターンは前の章で紹介されたゲートウェイ集約パターンに似ています.ここでのフラグメントゲートウェイの役割はゲートウェイ集約のAPIゲートウェイの役割と似ています.これは、複数のフラグメントへのアクセスの面倒を見て、レイアウトサーバーからの責任を分離し、フロントエンドからのインターフェイスを統一します.
例を見てみましょう.使用するアーキテクチャを次の図に示しますHypernova マイクロフロントエンド
ここで、レイアウトサーバはレールで構成され、フラグメントゲートウェイはノードで構成される.
1 )レイアウトサーバはサーバのデータを作成し、2 )ゲートウェイをフラグメント化するよう要求します.3 .フラグメントゲートウェイはデータをコンポーネントに渡し、最後にデータを返すHTMLを返します.1 .
フラグメントゲートウェイの役割は、レイアウトサーバの視点から抽象的な断片をAPIとして、SSR対応コンポーネントとして多種多様な断片を扱うためのゲートウェイになることです.さらに、フラグメントの側でどんなフレームワークを使用しても、フラグメントゲートウェイは既存のサーバアーキテクチャを変更せずにそれを扱うことができます2 .
以上がレイアウトサーバ+フラグメントゲートウェイの基本アーキテクチャです.OpenSponent、Podium、およびPuzzlejsを含むこのパターンでサーバー側の構成を行うことができるいくつかのフレームワークがあります.
テーラー
ここでは、私は図書館と呼ばれるTailor .
テーラーは、レイアウトサーバー+フラグメントゲートウェイのパターンではなく、より洗練されたレイアウトサーバー、いくつかのユニークな機能を組み立てるフラグメントの面で.
テーラーでは、次のようにしてフラグメントを解決できます
<html>
<head>
<script type="fragment" src="http://assets.domain.com"></script>
</head>
<body>
<fragment src="http://header.domain.com"></fragment>
<fragment src="http://content.domain.com" primary></fragment>
<fragment src="http://footer.domain.com" async></fragment>
</body>
</html>
primary async .ストリーミング
フラグメントはストリームとして配送されるので、すべてのフラグメントが完了するのを待つ必要はありません.
資産
SSRの断片は、JS/CSSの資産が必要なことを意味します.
テーラーは、リンクヘッダーの資産情報に対応します.これについての良いことは、あなたがロードするTailorに資産を伝えることができるということです.例えば、ハッシュのある資産に対して以下の応答を考慮する
fragment.ctfvygbh.js
概要
レイアウトサーバー機能に焦点を当てたテーラーのライブラリを使用すると、TFTBとアセットマネージメントの最適化をしながら、マイクロフロントエンド消費者の一部に関する考慮事項を減らす.
フレームワーク
ARAフレームワークは超新星に基づいており、マイクロフロントエンドを構築するためのCLIとモジュールのセットを提供します.その中でもサーバ側の構成はユニークである.
全体像は次の通りである.
詳細はこちらDoc , しかし、ここで私はちょうど概要を与える.
ストレンラーパターン
まず第一にAuthor's Medium は、ALAフレームワークを念頭に置いて、Stranglerパターンで設計されて示します.
例えば、モノリシックなアプリケーションビルトインRailsまたはLaravelを想像して、マイクロフロントエンドに適しているアーキテクチャに徐々にそれを再評価してください.
からMicrosoft Cloud Design Patterns )
以下、この仮定に基づいて説明する.
ノバプロキシ
Novaプロキシは既存のアプリケーションの間にある逆プロキシで、ブラウザからリクエストを受け取り、HTMLをレンダリングします.
PHPサーバーはデータ層と通信し、HTMLを生成する際にプレースホルダは事前に埋め込まれ、NOVAプロキシに返されます.
Nova proxyは受信したHTMLを解析し、プレースホルダに埋め込まれたデータをNovaクラスタへのペイロードとして要求する.そのジョブは、プレースホルダを返されたフラグメントと置換する.この層は、例えばフォールバックやタイムアウトの処理にも責任がある.
ノヴァクラスター
Novaクラスタはこの章のフラグメントゲートウェイです.
NOVAクラスタは、NOVAプロキシからデータを複数の断片に一度に受け取ります.それが受け取るリクエストに基づいて、ノヴァクラスタは各々の断片を質問して、HTMLを生成して、それをNOVAプロキシに返します.
概要
このアーキテクチャにより,既存のサーバはマイクロフロントエンドの意識を減らし,データを構築することに集中できる.また、責任を打破し、徐々に既存のレンダリングロジックをNOVAプロキシに動かし、バックエンド層をAPIとしてデカップリングすることもできます.
賛否両論
長所
サーバー側の構成が達成できるものの一つはSSRです.別の利点は、ストリームで実装できることです.加えて、例えばフラグメントゲートウェイを提供することによって、顧客はもはやフラグメントにマルチプル要求をしなければならない.この種のパフォーマンスとSEO要件はいくつかのアプリケーションに必須であるかもしれません.その場合、サーバー側の構成は実装される必要があります.
また、既存のモノリシックサーバ側アプリケーションをマイクロサービスに分解する場合は、フロントエンドとバックエンドを緩く結合する必要があります.ALAフレームワークの例に示すように、サーバ側の構成は、レガシーモノリシックアプリケーションが徐々にリファクタリングされる場合を柔軟に扱うことができる.
短所
あなたが気づいたかもしれないように、欠点の1つは、複雑さの増加です.フロントエンドだけではなくアーキテクチャを考慮する必要があり、サーバーリソースが存在するため、可用性とスケーラビリティを設計する必要があります.これらがどのように組織の開発効率を最終的に改善するかを意識することは常に重要です.
これは一般的にマイクロフロントエンドにも当てはまるが、まだ事実上の技術はない.既存のシステムと課題意識は組織と組織とが異なるので、各社がベストを発揮するような状況であり、その力を持つ企業はソフトウェアオープンソースを作る(したがって、この章で紹介されているライブラリのアーキテクチャは異なる).ライブラリやフレームワークのデザインコンセプトを理解する必要があります.
概要
この章では、サーバー側の構成といくつかのライブラリのアーキテクチャを紹介します.私は、サーバー側の構成で、我々は現実世界の複雑な課題を考えながら便利になる柔軟なアーキテクチャを採用することができます信じています.
hypernova-${client} この場合hypernova-ruby ) への抽象的なリクエストhypernova/server . 参照GitHub 詳細は畝↩ 私は、これが同様にマイクロサービスの場合について議論されると確信します、しかし、組織はフレームワークを整列するかどうかの一般的な理解が必要であると思います.まず第一に、インタフェースとしてフレームワークagnosticを持つことは、より自然であることが分かる.各チームが独立して技術を選択できるという事実は、マイクロフロントエンドの本来の考えにも近い.しかし、実際には、さまざまなフレームワーク(結合層の複雑さ、バンドルサイズ、会社内のホイールを再発明)について考えることが多くあり、また、“ギルド”スタイルで情報を共有することができる利点があります.ユーザー側のユースケースについて考える必要があります.畝↩
Reference
この問題について(マイクロフロントエンドパターン12 . 12:サーバ側構成), 我々は、より多くの情報をここで見つけました https://dev.to/okmttdhr/micro-frontends-patters-13-server-side-composition-1of5テキストは自由に共有またはコピーできます。ただし、このドキュメントのURLは参考URLとして残しておいてください。
Collection and Share based on the CC Protocol