シングルページアプリケーション (SPA) エディター機能には、 AEM 6.4 service pack 2 以降
SPA エディターは、SPA フレームワークを基にしたクライアントサイドレンダリング(React など)が必要なプロジェクトで有効なソリューションです。
このドキュメントで説明する SPA サーバー側のレンダリング機能を使用するには、AEM 6.4.5.0 以降が必要です。
シングルページアプリケーション (SPA) では、多くの場合、ネイティブアプリケーションと同様に、使い慣れた方法で反応し動作する、豊富で動的なエクスペリエンスをユーザーに提供できます。 これは、コンテンツを事前に読み込こんでからユーザーとのやり取りを処理するという負荷のかかる作業をクライアントにまかせることで、クライアントとサーバーの間で必要な通信量を最小限に抑え、アプリケーションの反応を良くすることで達成できます。
ただし、SPA のサイズが大きくコンテンツが豊富な場合などは、初期読み込み時間が長くなる可能性があります。読み込み時間を最適化するために、コンテンツの一部はサーバーサイドでレンダリングできます。サーバーサイドレンダリング(SSR)を使用すると、ページの初期読み込みが高速化し、その後、クライアントにさらにレンダリングを渡すことができます。
SSR が必要なのは一部のプロジェクトだけです。AEM は SPA 向けに JS SSR を完全にサポートしていますが、すべてのプロジェクトに対して体系的に JS SSR を実装することは推奨していません。
SSR を実装することに決めたら、長期的なメンテナンスを含め、SSR を追加することがプロジェクトにとって現実的にどのような複雑さ、労力、コストをもたらすかをまず評価する必要があります。SSR アーキテクチャは、付加価値が予測コストを明確に上回る場合にのみ選択する必要があります。
次の質問のいずれかへの答えが明確に「はい」である場合、通常、SSR には価値があります。
この 2 つの質問のうち少なくとも 1 つに対して明確な「はい」で回答した場合にのみ、プロジェクトで SSR の実装をAdobeにお勧めします。 次の節では、Adobe I/O Runtime を使用してこれをおこなう方法について説明します。
次の場合、 プロジェクトに SSR の実装が必要であることを確認するを使用する場合、Adobeにお勧めのソリューションはAdobe I/O Runtimeを使用することです。
Adobe I/O Runtime について詳しくは、以下を参照してください。
次の節では、2 つの異なるモデルで、SPA に SSR を実装する際に Adobe I/O Runtime を使用する方法について詳しく説明します。
アドビでは、環境(ステージング、実稼動、テストなど)ごとに個別の Adobe I/O Runtime ワークスペースを使用することをお勧めします。これにより、異なる環境にデプロイされた単一アプリケーションの異なるバージョンを使用する、一般的なシステム開発ライフサイクル(SDLC)パターンを使用できます。ドキュメントを参照 Project App Builder アプリケーション用 CI/CD を参照してください。
インスタンスタイプごとのランタイム実装に違いがない限り、インスタンス(オーサー、パブリッシュ)ごとに個別のワークスペースは必要ありません。
AEM は、リモートレンダリングされたコンテンツをどこで取得できるかを把握している必要があります。次に関係なく SSR に実装するモデルを使用する場合は、このリモートレンダリングサービスへのアクセス方法をAEMに指定する必要があります。
これは、 RemoteContentRenderer - Configuration Factory OSGi サービスを介しておこなわれます。http://<host>:<port>/system/console/configMgr
の Web コンソール設定コンソールで、文字列「RemoteContentRenderer」を検索します。
この設定では、次のフィールドを使用できます。
key=value
を実装するかどうかに関係なく AEM主導の通信フロー または Adobe I/O Runtime駆動流に値を指定する場合は、リモートコンテンツレンダラー設定を定義する必要があります。
この設定では、 リモートコンテンツレンダラー:追加の拡張機能とカスタマイズオプションを使用できます。
SSR を使用する場合、 コンポーネントインタラクションワークフロー AEMのSPAのには、アプリの初期コンテンツがAdobe I/O Runtimeによって生成される段階が含まれます。
セクション AEM主導の通信フロー AEMがブートストラップとコンテンツの提供を実行するAEMのSPAに関する、サーバーサイドレンダリングの標準および推奨される実装について説明します。
あるいは、SSR を実装して通信フローを効果的に逆転させ、Adobe I/O Runtime がブートストラップをおこなうようにすることもできます。
どちらのモデルも AEM で有効でサポートされています。ただし、特定のモデルを実装する前に、それぞれのメリットとデメリットを考慮する必要があります。
ブートストラップ | メリット | デメリット |
---|---|---|
AEM 経由 | AEMは、必要に応じてライブラリの挿入を管理します リソースの管理はAEMでのみ必要です |
SPA デベロッパーに馴染みのない場合がある |
Adobe I/O Runtime 経由 | SPA デベロッパーに馴染みがある | AEM開発者は、CSS や JavaScript など、アプリケーションに必要な Clientlib リソースを、 allowProxy プロパティリソースはAEMとAdobe I/O Runtimeの間で同期する必要がある SPAのオーサリングを有効にするには、Adobe I/O Runtimeのプロキシサーバーが必要になる場合があります |
通常は、アプリケーションの一部のみをサーバーサイドでレンダリングする必要があります。一般的な例としては、ページの初回読み込み時に一画面に表示されるコンテンツは、サーバーサイドでレンダリングする必要があります。 既にレンダリングされたコンテンツをクライアントに配信することで時間を節約できます。ユーザーが SPA とやり取りすると、追加のコンテンツがクライアントによってレンダリングされます。
SPAにサーバーサイドレンダリングを実装する場合は、SSR が必要なアプリの部分を確認する必要があります。
SPA コンポーネントは、クライアント(ブラウザー内)またはサーバーサイドでレンダリングできます。サーバーサイドでレンダリングすると、ウィンドウのサイズや位置などのブラウザーのプロパティは存在しません。したがって、SPA のコンポーネントは、レンダリングされる場所を前提としない、同型のものである必要があります。
SSR を活用するには、サーバーサイドレンダリングを担当する Adobe I/O Runtime だけでなく、AEM にもコードをデプロイする必要があります。ほとんどのコードは同じですが、サーバー固有のタスクは異なります。
AEM の SPA 向け SSR では、Adobe I/O Runtime が必要です。これは、アプリケーションコンテンツサーバーサイドのレンダリングのために呼び出されます。アプリの HTL 内で、コンテンツをレンダリングするために Adobe I/O Runtime のリソースが呼び出されます。
AEM が標準で Angular および React SPA フレームワークをサポートするのと同様に、Angular および React アプリケーションでもサーバーサイドレンダリングがサポートされます。詳しくは、両方のフレームワークの NPM ドキュメントを参照してください。
単純な例については、We.Retail ジャーナルアプリを参照してください。アプリケーションサーバー側全体をレンダリングします。これは実際の例ではありませんが、SSR の実装に必要な事項を示しています。
We.Retail ジャーナルアプリはデモの目的でのみ使用され、推奨される Adobe I/O Runtime の代わりに、Node.js を単純な例として使用します。この例は、どのプロジェクト作業にも使用しないでください。
AEM プロジェクトでは、 AEM プロジェクトアーキタイプを活用します。このアーキタイプは、React または Angular を使用する SPA プロジェクトをサポートし、SPA SDK を活用します。
Adobe I/O Runtime は、AEM にSPA 用の SSR を実装する場合に推奨されるソリューションです。
オンプレミスの AEM インスタンスの場合は、上記と同じ方法で、カスタム Node.js インスタンスを使用して SSR を実装することもできます。これはアドビでサポートされていますが、お勧めしません。
Node.js は、アドビがホストする AEM インスタンスではサポートされていません。
SSR を Node.js 経由で実装する必要がある場合、アドビでは AEM 環境(オーサー、パブリッシュ、ステージなど)ごとに個別の Node.js インスタンスを使用することをお勧めします。
AEM で SSR を SPA と使用するために必要なリモートコンテンツレンダラー設定は、ニーズに合わせて拡張およびカスタマイズできる、より一般化されたレンダリングサービスです。
RemoteContentRenderingService
は、Adobe I/O からなど、リモートサーバーでレンダリングされるコンテンツを取得する OSGi サービスです。リモートサーバーに送信されるコンテンツは、渡されたリクエストパラメーターに基づきます。
RemoteContentRenderingService
は、追加のコンテンツ操作が必要な場合に、カスタム Sling モデルまたはサーブレットに依存関係を反転してインジェクトできます。
このサービスは、RemoteContentRendererRequestHandlerServlet によって内部的に使用されます。
RemoteContentRendererRequestHandlerServlet
を使用して、要求の設定をプログラムで作成できます。DefaultRemoteContentRendererRequestHandlerImpl
では、デフォルトのリクエストハンドラーの実装が提供されており、コンテンツ構造内の場所をリモートエンドポイントにマップするために、複数の OSGi 設定を作成できます。
カスタム要求ハンドラーを追加するには、RemoteContentRendererRequestHandler
インターフェイスを実装します。Constants.SERVICE_RANKING
コンポーネントプロパティは、100(DefaultRemoteContentRendererRequestHandlerImpl
のランク)より大きい整数に設定してください。
@Component(immediate = true,
service = RemoteContentRendererRequestHandler.class,
property={
Constants.SERVICE_RANKING +":Integer=1000"
})
public class CustomRemoteContentRendererRequestHandlerImpl implements RemoteContentRendererRequestHandler {}
デフォルトハンドラーの設定は、「リモートコンテンツレンダラーの設定」の説明に従って作成する必要があります。
### リモートコンテンツレンダラーの使用
サーブレットがページにインジェクト可能なコンテンツを取得して返すには、以下をおこないます。
通常、ページコンポーネントの HTL テンプレートは、この機能のメイン受信者です。
<sly data-sly-resource="${resource @ resourceType='cq/remote/content/renderer/request/handler'}" />
このサーブレットでは、Sling モデルエクスポーターを活用してコンポーネントデータをシリアライズします。デフォルトでは、com.adobe.cq.export.json.ContainerExporter
および com.adobe.cq.export.json.ComponentExporter
の両方が Sling モデルアダプターとしてサポートされています。必要に応じて、RemoteContentRendererServlet
を使用して RemoteContentRendererRequestHandler#getSlingModelAdapterClasses
を実装するように要求を適合させる必要があるクラスを追加できます。追加のクラスは、ComponentExporter
を拡張する必要があります。