Show Menu
SUJETS×

SPA et rendu côté serveur

Les applications d’une seule page (SPA) peuvent offre à l’utilisateur une expérience riche et dynamique qui réagit et se comporte de manière familière, souvent comme une application native. Pour ce faire, le client doit charger le contenu à l’avance, puis gérer l’interaction utilisateur de manière intensive, ce qui réduit le volume de communication nécessaire entre le client et le serveur, ce qui rend l’application plus réactive.
Toutefois, cela peut entraîner des temps de chargement initiaux plus longs, en particulier si le SPA est volumineux et riche en contenu. Pour optimiser les temps de chargement, une partie du contenu peut être rendue côté serveur. L’utilisation du rendu côté serveur (SSR) peut accélérer le chargement initial de la page, puis transmettre le rendu au client.

Quand utiliser SSR

SSR n'est pas requis pour tous les projets. Bien que AEM appuie pleinement la stratégie SSR JS pour l'application d'une seule page, l'Adobe ne recommande pas sa mise en oeuvre systématique pour chaque projet.
Lorsque vous décidez de mettre en oeuvre des SSR, vous devez d'abord estimer la complexité, les efforts et les coûts supplémentaires associés à l'ajout de SSR de façon réaliste pour le projet, y compris la maintenance à long terme. Une architecture SSR ne devrait être choisie que lorsque la valeur ajoutée dépasse clairement les coûts estimés.
Le SSR fournit habituellement une certaine valeur lorsqu'il y a un "oui" clair à l'une ou l'autre des questions suivantes :
  • SEO : Est-il toujours nécessaire d'utiliser la SSR pour que votre site soit correctement indexé par les moteurs de recherche qui génèrent du trafic ? Gardez à l’esprit que les principaux moteurs de recherche évaluent désormais JS.
  • Vitesse de la page : Est-ce que la SSR améliore la vitesse de façon mesurable dans les environnements réels et ajoute à l'expérience globale de l'utilisateur ?
Ce n'est que lorsqu'au moins l'une de ces deux questions reçoit une réponse "oui" clair pour votre projet que l'Adobe recommande la mise en oeuvre de la SSR. Les sections suivantes décrivent comment utiliser Adobe I/O Runtime.

Adobe I/O Runtime

Si vous pensez que votre projet nécessite la mise en oeuvre de la SSR , la solution recommandée par l'Adobe est d'utiliser Adobe I/O Runtime.
Pour plus d’informations sur Adobe I/O Runtime, voir
Les sections suivantes décrivent comment Adobe I/O Runtime peut être utilisé pour implémenter la technologie SSR pour votre application monopage dans deux modèles différents :
adobe recommande une instance Adobe I/O Runtime distincte pour chaque environnement AEM (auteur, publication, étape, etc.).

Configuration du rendu à distance

aem doit savoir où le contenu rendu à distance peut être récupéré. Quel que soit le modèle que vous choisissiez de mettre en oeuvre pour SSR, vous devrez indiquer pour AEM comment accéder à ce service de rendu à distance.
Ceci est effectué via le service OSGi RemoteContentRenderer - Configuration Factory. Recherchez la chaîne "RemoteContentRenderer" dans la console de configuration de la console Web à http://<host>:<port>/system/console/configMgr .
Les champs suivants sont disponibles pour la configuration :
  • Modèle de chemin de contenu - expression régulière afin de correspondre à une partie du contenu, si nécessaire
  • URL du point de terminaison distant - URL du point de terminaison responsable de la génération du contenu
    • Utilisez le protocole HTTPS sécurisé si ce n'est pas sur le réseau local.
  • En-têtes de demande supplémentaires - En-têtes supplémentaires à ajouter à la demande envoyée au point de terminaison distant
    • Modèle: key=value
  • Délai d’expiration de la demande - Délai d’expiration de la demande d’hôte distant en millisecondes
Que vous choisissiez de mettre en oeuvre le flux de communication AEM ou le flux de communication Adobe I/O Runtime, vous devez définir une configuration de rendu de contenu à distance.
Cette configuration exploite le Remote Content Renderer, qui offre des options d’extension et de personnalisation supplémentaires.

Flux de communication AEM

Lors de l’utilisation de la technologie SSR, le processus d’interaction des composants des applications monopages en AEM inclut une phase au cours de laquelle le contenu initial de l’application est généré sur Adobe I/O Runtime.
  1. Le navigateur demande le contenu de la SSR à AEM.
  2. aem publie le modèle à Adobe I/O Runtime.
  3. Adobe I/O Runtime renvoie le contenu généré.
  4. aem diffuse le code HTML renvoyé par Adobe I/O Runtime via le modèle HTML du composant de page d’arrière-plan.

Flux de communication piloté par Adobe I/O Runtime

La section précédente décrit l’implémentation standard et recommandée du rendu côté serveur en ce qui concerne les applications monopages en AEM, où AEM effectue l’amorçage et la diffusion du contenu.
Une autre solution consiste à mettre en oeuvre la SSR de sorte que Adobe I/O Runtime soit responsable de l'amorçage, inversant ainsi le flux de communication.
Les deux modèles sont valides et pris en charge par AEM. Toutefois, il faut tenir compte des avantages et des inconvénients de chacun avant de mettre en oeuvre un modèle particulier.
Démarrage Avantages Inconvénients
via AEM
  • aem gère les bibliothèques d’injection si nécessaire.
  • Les ressources ne doivent être maintenues que sur AEM
  • Peut-être pas familier avec les développeurs d’applications monopages
via Adobe I/O Runtime
  • Plus familier aux développeurs d’applications monopages
  • Les ressources de bibliothèque cliente requises par l'application, telles que CSS et JavaScript, devront être rendues disponibles par le développeur AEM via la allowProxy propriété
  • Les ressources doivent être synchronisées entre AEM et Adobe I/O Runtime
  • Pour activer la création de l’application d’une seule page, un serveur proxy pour Adobe I/O Runtime peut être nécessaire.

Planification de la SSR

En règle générale, seule une partie d’une application doit être rendue côté serveur. L’exemple courant est le contenu qui s’affichera au-dessus du pli lors du chargement initial de la page est rendu côté serveur. Cela permet de gagner du temps en fournissant au client du contenu déjà rendu. Lorsque l’utilisateur interagit avec l’application d’une seule page, le contenu supplémentaire est rendu par le client.
Lorsque vous envisagez d’implémenter le rendu côté serveur pour votre application monopage, vous devez vérifier les parties de l’application qui seront nécessaires.

Développement d’une application d’une seule page à l’aide d’une SSR

Les composants SPA peuvent être rendus par le client (dans le navigateur) ou côté serveur. Lorsqu’il est rendu côté serveur, les propriétés du navigateur telles que la taille de la fenêtre et l’emplacement ne sont pas présentes. Par conséquent, les composants de l'APS doivent être isomorphiques, sans présumer de l'endroit où ils seront rendus.
Pour utiliser la technologie SSR, vous devez déployer votre code dans AEM et sur Adobe I/O Runtime, qui est responsable du rendu côté serveur. La plupart du code sera identique, mais les tâches spécifiques au serveur seront différentes.

SSR pour les applications monopages en AEM

Les applications SSR pour les applications monopages en AEM nécessitent Adobe I/O Runtime, qui est appelé pour le rendu côté serveur de contenu d’application. Dans le fichier HTL de l’application, une ressource sur Adobe I/O Runtime est appelée pour générer le contenu.
Tout comme AEM prend en charge les structures d’application monopages Angular et React prêtes à l’emploi, le rendu côté serveur est également pris en charge pour les applications Angular et React. Pour plus d'informations, consultez la documentation du mécanisme national de prévention pour les deux cadres.

Rendu de contenu distant

La configuration de Remote Content Renderer qui est requise pour utiliser SSR avec votre application d’une seule page d’accueil dans AEM appuie sur un service de rendu plus généralisé qui peut être étendu et personnalisé pour répondre à vos besoins.

RemoteContentRenderingService

RemoteContentRenderingService est un service OSGi permettant de récupérer le contenu rendu sur un serveur distant, par exemple à partir des E/S d’Adobe. Le contenu envoyé au serveur distant est basé sur le paramètre de requête transmis.
RemoteContentRenderingService peut être injecté par inversion de dépendance dans un modèle Sling personnalisé ou une servlet lorsque des manipulations de contenu supplémentaires sont requises.
Ce service est utilisé en interne par la servlet RemoteContentRendererRequestHandlerServlet .

RemoteContentRendererRequestHandlerServlet

Il RemoteContentRendererRequestHandlerServlet peut être utilisé pour définir par programmation la configuration de la requête. DefaultRemoteContentRendererRequestHandlerImpl , l’implémentation du gestionnaire de requêtes par défaut fournie vous permet de créer plusieurs configurations OSGi afin de mapper un emplacement dans la structure de contenu à un point de terminaison distant.
Pour ajouter un gestionnaire de requêtes personnalisé, implémentez l’ RemoteContentRendererRequestHandler interface. Veillez à définir la propriété Constants.SERVICE_RANKING du composant sur un nombre entier supérieur à 100, qui correspond au classement du DefaultRemoteContentRendererRequestHandlerImpl .
@Component(immediate = true,
        service = RemoteContentRendererRequestHandler.class,
        property={
            Constants.SERVICE_RANKING +":Integer=1000"
        })
public class CustomRemoteContentRendererRequestHandlerImpl implements RemoteContentRendererRequestHandler {}

Configuration d’OSGi du gestionnaire par défaut

La configuration du gestionnaire par défaut doit être configurée comme décrit dans la section Configuration du rendu de contenu distant.

Utilisation du rendu de contenu distant

Pour qu’une servlet récupère et renvoie du contenu qui peut être injecté dans la page :
  1. Assurez-vous que votre serveur distant est accessible.
  2. ajoutez l’un des fragments de code suivants sur le modèle HTML d’un composant AEM.
  3. Vous pouvez éventuellement créer ou modifier les configurations OSGi.
  4. Parcourir le contenu de votre site
En général, le modèle HTML d’un composant de page est le principal destinataire d’une telle fonctionnalité.
<sly data-sly-resource="${resource @ resourceType='cq/remote/content/renderer/request/handler'}" />

Conditions requises

Les servlets tirent parti de Sling Model Exporter pour sérialiser les données du composant. Par défaut, les cartes com.adobe.cq.export.json.ContainerExporter et com.adobe.cq.export.json.ComponentExporter sont prises en charge en tant que cartes de modèle Sling. Si nécessaire, vous pouvez ajouter des classes que la requête doit être adaptée pour utiliser la RemoteContentRendererServlet et mettre en oeuvre la RemoteContentRendererRequestHandler#getSlingModelAdapterClasses . Les classes supplémentaires doivent étendre le ComponentExporter .