JSSトポロジー
このページの翻訳はAIによって自動的に行われました。可能な限り正確な翻訳を心掛けていますが、原文と異なる表現や解釈が含まれる場合があります。正確で公式な情報については、必ず英語の原文をご参照ください。
JSSは、ほとんどのDevOps展開プロセスに適合するよう設計された柔軟な技術です。JSSサイトは複数の異なるトポロジーで展開可能です。ヘッドレス技術として、どちらを選ぶべきか迷っている場合は、JSSの最大の利点を活かすためにヘッドレス展開を選んでください。
ヘッドレス位相
ヘッドレストポロジーでは、従来のSitecore XP(またはXM)展開が、コンテンツやレイアウトデータを提供するAPIサーバーに変換され、パーソナライズが事前に適用されます。
!注このトピックでは、JSSとのやり取り以外でのSitecore展開の設定方法については扱いません。JSS以外にもSitecoreのデフォルトの展開トポロジー があります。
以下の図は、ヘッドレストポロジーを使用した場合のアプリユーザー、JSS、Sitecore間のリクエストフローを示しています。
ヘッドレスモードで動作する際、Sitecore Content Delivery(CD)サーバーは公開ウェブサイトに直接サービスを提供するわけではありません。代わりに、安価なNode.jsサーバーのクラスターが公開ウェブサイトをホストします。これらのNodeサーバーはnode-headless-ssr-proxyを実行します。このサーバーサイドレンダリング(SSR)プロキシは、SitecoreのCDサーバー上で動作するAPIにリクエストを送り、JSSアプリケーションをHTMLにレンダリングしてからクライアントに返します。これらのSSRプロキシはNode.jsが動作するどこでもホスト可能です。
ヘッドレストポロジーでは、プライベートSitecore CDサーバーを使用できます。SSRプロキシは、API通話やメディアライブラリリクエストなど特定のパスをSitecore CDにリバースプロキシすることもできます。この構成では、JSSアプリは プロキシURLをAPIサーバー( https://www.mysite.com)として使い、SSRプロキシプロキシはhttps://sitecore-cds.mysite.com。
SSRプロキシの使用を避け、アプリがAPIデータで埋める静的なHTMLファイルを提供できます。これによりNodeホスティングの必要性がなくなります。しかし、クライアントのみレンダリングを使う場合、一部の検索エンジンはコンテンツのインデックス化に問題を抱えることがあります。HTMLはJavaScript実行がなければほとんど空白です。一部の検索エンジンはJavaScriptを実行していますが、検索エンジンのJavaScriptレンダリング処理の不整合性から、SSRは依然として現在のベストプラクティスです。
積分位相
統合トポロジーでは、Sitecore CDサーバーは自社の統合された(同じサーバーでプロセス外の)Node.jsサービスを使ってJSSアプリのサーバー側レンダリングを行います。このモードは、特にCDN統合やAPIサーバーをSSRインスタンスから別々にスケーリングできる能力において、ヘッドレス展開に比べて柔軟性が劣ります。このモードでは、APIホスティングとレンダリングが同じサーバー上で行われます。
また、統合トポロジーを使用する場合は、リクエストがSitecoreによって事前解析され、Sitecoreルーティングの対象となるため、高度なクライアント側ルーティングシナリオの柔軟性が低くなります。ヘッドレスモードでは、カスタムExpressミドルウェアを実行してサーバーを広範囲にカスタマイズできます。統合モードでは、同様のカスタマイズは代わりにSitecore(C#)で行う必要があります。
以下の図は、統合トポロジーを使用した場合のアプリユーザー、JSS、Sitecore間のリクエストフローを示しています。
!注重負荷の生産シナリオでは統合モードは推奨しません。なぜなら、ページ全体が個別のレンダリングではなく、Node.jsを用いてサーバーサイドでブロックとしてレンダリングされているからです。したがって、従来の出力キャッシュメカニズムはオール・オア・ナッシング(すべてか無か)になります。つまり、キャッシュを有効にするとページ全体のキャッシュを強制的に処理し、ほとんどの場合望ましいものではありません。