ハイブリッドストアフロントのガイダンス

B2C Commerce のハイブリッド実装では、Storefront Reference Architecture (SFRA) およびスクリプト API を、コンポーザブルストアフロントおよび SCAPI と組み合わせることができます。たとえば、SFRA でチェックアウト機能を提供しながら、商品詳細ページ (PDP) と商品一覧ページ (PLP) に PWA Kit を実装できます。Sitegenesis とコンポーザブルストアフロントを使用した実装は、正式にはサポートされていません。

このハイブリッドアプローチには、次の利点があります。

• 柔軟性とカスタマイズ性: 特定のビジネスニーズと顧客の期待に合わせたストアフロントを作成できます。
• 拡張性: コンポーザブルストアフロントのモジュール性により、要件の変化に合わせて簡単に拡張および適応できます。
• シームレスな統合: SCAPI は B2C Commerce Cloud とのシームレスな統合を保証し、幅広いコマース機能へのアクセスを提供します。
• ユーザーエクスペリエンスの向上: SCAPI のパワーとコンポーザブルストアフロントの柔軟性を組み合わせることで、企業はパーソナライズされた魅力的なショッピング体験を提供できます。

コンポーザブルストアフロントの実装の詳細については、ハイブリッド実装でのコンポーザブルストアフロントの使用を参照してください。

以下のセクションでは、ハイブリッドストアフロントの実装に関するベストプラクティスについて説明します。ハイブリッド実装に関するその他のガイダンスについては、ハイブリッド実装でのコンポーザブルストアフロントの使用を参照してください。

買い物カゴは、最初の商品を追加するときや、住所情報などの顧客情報を保存するときなど、必要な場合にのみ作成してください。これは一般的なベストプラクティスですが、ハイブリッドストアフロントでは特に重要です。

SFRA/SG (コントローラーベース) ストアフロントは Script API getCurrentOrNewBasket() を使用して買い物カゴを作成し、PWA Kit は SCAPI POST baskets を使用して買い物カゴを作成します。

ハイブリッドサイトを実装する場合は、ユースケースに最も適した API を利用します。たとえば、SFRA または SG で PDP を実装する場合は、Script API getCurrentOrNewBasket() を使用します。ハイブリッドサイトで PDP に PWA Kit を使用している場合は、SCAPI POST baskets を使用します。

このベストプラクティスは、空の買い物カゴを避けるために、事前ではなく、商品を追加するときにのみ買い物カゴを作成することに沿っています。

買い物カゴを管理するときは、非同期関数に注意してください。

• PWA Kit などのシングルページアプリケーション (SPA) は、SFRA などの従来のプラットフォーム開発モデルとは異なるリクエスト実行スタイルに従います。SPA はノンブロッキングアーキテクチャに重点を置き、API を非同期方法で使用して遅延読み込み、データのプリロード、またはユーザー操作の処理を行います。
• このリクエストアーキテクチャを慎重に検討し、どのタイプのリクエストがいつ、どこで、どのような順序で実行されるかを理解してください。
• 同じ種類のリクエスト (同じデータの更新) が並列で実行されると、これらのリクエストは互いに上書きされ、最後に完了したリクエストによって最終結果が生成されるため、予期しない動作が発生する可能性があります。たとえば、さまざまなデータの検証や依存関係など、複数のステップで作成された買い物カゴは、正しく実装されていないと競合状態が発生する可能性が高くなります。非同期設計パターン (Promise、async/await、コールバックなど) は、リクエストが互いの完了に依存する依存関係を管理し、潜在的な問題を回避するために必要です。

• getCurrentOrNewBasket() でフックに買い物カゴを作成しないでください。
• フックで getCurrentBasket() を使用することは避けてください。代わりに、渡された買い物カゴを使用します。例: dw.ocapi.shop.basket.afterPATCH

• 一般に、フックでの発信呼び出しは、他のシステムへの接続と遅延に関する潜在的な問題があるため、避ける必要があります。代わりに、これらの呼び出しは、サーバーランタイム、BFF (Backend For Frontend)、クライアントブラウザーなどのクライアントシステムによって開始する必要があります。特に、OCAPI と SCAPI への呼び出しは、内部呼び出しによってリソースがバインドされ、パフォーマンスとスケーラビリティに影響を与える可能性があるため、避けてください。さらに、同じオブジェクトがフックと発信呼び出しで変更されると、競合状態が発生し、予期しない動作が発生する可能性があります。推奨されるアプローチは、フックからそれぞれの Script API 関数を呼び出すか、クライアント側からフックの外部でそれぞれの SCAPI リソースを呼び出すことです。

これらは一般的なベストプラクティスですが、ハイブリッドストアフロントでは特に重要です。

セッションブリッジ (POST sessions および POST customers/auth) の使用を最小限に抑えます。新しいセッションは必要な場合にのみ作成し、既存のセッションはできるだけ再利用します。

最適なパフォーマンスを確保するために、SCAPI/OCAPI 呼び出しの JWT 作成にも同じアプローチを適用します。