Experience Edgeのベストプラクティス
このページの翻訳はAIによって自動的に行われました。可能な限り正確な翻訳を心掛けていますが、原文と異なる表現や解釈が含まれる場合があります。正確で公式な情報については、必ず英語の原文をご参照ください。
このトピックで推奨される実践に従い、Experience Edgeをより効率的に活用してください。
Context IDをブラウザに公開するのは避けてください
プレビュー用GraphQL APIとDelivery GraphQL APIは、フロントエンドアプリからSitecoreへのリクエストを認証するためにコンテキストIDが必要です。もしアプリがブラウザから直接GraphQLリクエストを行う場合(クライアントサイドJavaScript)、Context IDはネットワークトラフィックやブラウザ開発者ツールで確認され、誰でも閲覧してSitecoreコンテンツのクエリに再利用できます。
クライアント側のクエリは、例えば「入力しながら検索する」ユーザーインターフェースや、パーソナライズされたコンテンツを遅く読み込む際に発生することがあります。
コンテキストIDを守るために、サーバー上に保管し、絶対にブラウザに届かせないようにしてください。これは、サーバーレス関数、APIルート、または同様のサーバーサイドプロキシを通じてクエリをルーティングすることで実現できます。こうしてブラウザはプロキシ(例えば /api/searchAPIルート)を呼び出し、プロキシはコンテキストIDを使ってGraphQLリクエストを行います。これにより、ブラウザはContext IDを一度もサーバーから離れないため、IDを認識しません。
静的またはサーバーレンダリングのコンテンツでは、GraphQLリクエストはそもそもサーバーから離れないため、明示的なプロキシは必要ありません。
プレビューとデリバリーの両方で大きなクエリをテストしてください
Preview GraphQL APIとDelivery GraphQL APIではクエリの複雑さの計算方法が異なるため、特にクエリ複雑度の上限に近い場合は、重要なクエリを両方のエンドポイントに対して検証することをお勧めします。
ページクエリにグローバルデータを含まないでください
プレビューGraphQL APIおよびDelivery GraphQL APIが返すレイアウトデータでは、レンダリングデータとそれが表現する特定のページがまとめられています。ナビゲーションメニューやフッターリンクなどのグローバルデータをページレベルの出力に埋め込むと、ナビゲーションアイテムの名前変更などグローバルデータの変更は、それを含むすべてのページを再公開しなければなりません。これは各ページのキャッシュを無効化し再生成する必要があるためです。
代わりに、専用のGraphQLクエリを使って、そのグローバルデータを別途取得してください。この方法なら、ナビゲーションの変更はその1回のクエリの結果を更新するだけで済み、サイト全体の再公開をトリガーしません。
ページのレイアウトサービス出力にグローバルデータを入力すると、データ変更には再公開が必要です。例えば、ページヘッダーやフッターで使われるナビゲーションデータなどです。代わりにレンダリングホストからのGraphQL呼び出しを使ってこのデータを取得することを検討してください。
GraphQLクエリで変数を使う
動的値をクエリ文字列に直接埋め込むのではなく 、変数 として渡してください。変数はクエリ構造をデータから分離し、文字列連結のリスクを減らし、クライアントやサーバーの動作をより安全かつ予測可能にします。変数を使うクエリはリクエスト間で安定した文字列を持つため、GraphQLサーバーは新しい文字列を再度解析する代わりに解析・検証済みのクエリドキュメントを再利用できます。その再利用は、解析や検証のオーバーヘッドを削減するパフォーマンス最適化です。
各クエリに一貫した記述的な操作名を付けます。同じクエリ形状でも名前は固定しておき、キャッシュヒットを最大化しましょう。意図的に別々のキャッシュ動作が必要な場合を除いて。 LayoutQueryのような安定した名前は、サーバーログやトレースツール、分析ツールで遅いクエリや失敗しているクエリを特定しやすくします。
Experience Edgeから内部サイトを除外する
SitecoreAIには内部の非生産サイトがあるかもしれません。これらのサイトやそのコンテンツがDelivery GraphQL API経由で利用できないようにするには、内部サイトとしてマークすることができます。