---
title: "JSSトポロジー"
slug: "jss-topologies"
abstract: "JSSアプリケーションで使用されるトポロジーの説明"
---
# JSSトポロジー

JSSは、ほとんどのDevOps展開プロセスに適合するよう設計された柔軟な技術です。JSSサイトは複数の異なるトポロジーで展開可能です。ヘッドレス技術として、どちらを選ぶべきか迷っている場合は、JSSの最大の利点を活かすためにヘッドレス展開を選んでください。

## ヘッドレス位相

*ヘッドレス*トポロジーでは、従来のSitecore XP(またはXM)展開が、コンテンツやレイアウトデータを提供するAPIサーバーに変換され、パーソナライズが事前に適用されます。

> !注このトピックでは、JSSとのやり取り以外でのSitecore展開の設定方法については扱いません。JSS以外にも[Sitecoreのデフォルトの展開トポロジー](https://doc.sitecore.com/xp/en/developers/102/platform-administration-and-architecture/default-topologies.html) があります。

以下の図は、ヘッドレストポロジーを使用した場合のアプリユーザー、JSS、Sitecore間のリクエストフローを示しています。

![Sitecore JSS topology diagram](https://doc.sitecore.com/api/markdown-image/xp/ja/developers/hd/19/sitecore-headless-development/images/headless-topology.svg)

[ヘッドレスモードで](https://doc.sitecore.com/xp/ja/developers/hd/19/sitecore-headless-development/headless-server-side-rendering-mode.html "Headless server-side rendering mode")動作する際、Sitecore Content Delivery(CD)サーバーは公開ウェブサイトに直接サービスを提供するわけではありません。代わりに、安価なNode.jsサーバーのクラスターが公開ウェブサイトをホストします。これらのNodeサーバーは[node-headless-ssr-proxy](https://github.com/Sitecore/jss/tree/release/19.0.0/samples/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間のリクエストフローを示しています。

![Sitecore JSS integrated topology diagram](https://doc.sitecore.com/api/markdown-image/xp/ja/developers/hd/19/sitecore-headless-development/images/integrated-topology.svg)

> !注重負荷の生産シナリオでは統合モードは推奨しません。なぜなら、ページ全体が個別のレンダリングではなく、Node.jsを用いてサーバーサイドでブロックとしてレンダリングされているからです。したがって、従来の出力キャッシュメカニズムはオール・オア・ナッシング(すべてか無か)になります。つまり、キャッシュを有効にするとページ全体のキャッシュを強制的に処理し、ほとんどの場合望ましいものではありません。