Show Menu
TEMAS×

SPA y procesamiento del lado del servidor

El Editor de SPA es la solución recomendada para proyectos que requieren procesamiento del cliente basado en el marco de SPA (por ejemplo, React o Angular).
Se requiere AEM 6.5.1.0 o posterior para utilizar las funciones de procesamiento del lado del servidor SPA tal como se describe en este documento.

Información general

Las aplicaciones de una sola página (SPA) pueden oferta al usuario de una experiencia dinámica y rica que reacciona y se comporta de maneras conocidas, a menudo como una aplicación nativa. Esto se consigue confiando en que el cliente cargue el contenido por adelantado y, a continuación, lleve a cabo el trabajo pesado de gestionar la interacción del usuario y, de este modo, se minimiza la cantidad de comunicación necesaria entre el cliente y el servidor, lo que hace que la aplicación sea más reactiva.
Sin embargo, esto puede llevar a tiempos de carga iniciales más largos, especialmente si el SPA es grande y rico en su contenido. Para optimizar los tiempos de carga, parte del contenido se puede representar en el servidor. El uso del procesamiento en el lado del servidor (SSR) puede acelerar la carga inicial de la página y, a continuación, pasar el procesamiento al cliente.

Cuándo utilizar SSR

No es necesaria la reforma del sector de la seguridad en todos los proyectos. Aunque AEM es totalmente compatible con JS SSR para SPA, Adobe no recomienda implementarlo sistemáticamente en todos los proyectos.
Al decidir implementar SSR, primero debe calcular qué complejidad adicional, esfuerzo y costo de adición de SSR representa de manera realista para el proyecto, incluido el mantenimiento a largo plazo. La arquitectura de SSR sólo debe elegirse cuando el valor añadido exceda claramente los costes estimados.
SSR suele proporcionar algún valor cuando hay un claro "sí" a cualquiera de las siguientes preguntas:
  • SEO: ¿Es aún necesario realizar la SSR para que los motores de búsqueda que traen tráfico indiquen correctamente el sitio? Tenga en cuenta que los rastreadores de motores de búsqueda principales ahora evalúan JS.
  • Velocidad de página: ¿Proporciona la SSR una mejora de velocidad medible en los entornos de la vida real y contribuye a la experiencia general del usuario?
Solo cuando al menos una de estas dos preguntas se conteste con un claro "sí" para su proyecto, Adobe recomienda implementar SSR. Las siguientes secciones describen cómo hacerlo con Adobe I/O Runtime.

Adobe I/O Runtime

Si está seguro de que su proyecto requiere la implementación de SSR , la solución recomendada de Adobe es utilizar Adobe I/O Runtime.
Para obtener más información sobre Adobe I/O Runtime, consulte
Las siguientes secciones detallan cómo se puede utilizar Adobe I/O Runtime para implementar SSR para su SPA en dos modelos diferentes:
Adobe recomienda una instancia de Adobe I/O Runtime independiente para cada entorno de AEM (autor, publicación, etapa, etc.).

Configuración del procesador remoto

AEM debe saber dónde se puede recuperar el contenido procesado de forma remota. Independientemente del modelo que elija implementar para SSR, deberá especificar a AEM cómo acceder a este servicio de procesamiento remoto.
Esto se realiza mediante el servicio ​RemoteContentRenderer - Configuration Factory OSGi. Busque la cadena "RemoteContentRenderer" en la consola de configuración de la consola web en http://<host>:<port>/system/console/configMgr .
Los siguientes campos están disponibles para la configuración:
  • Patrón de ruta de contenido: expresión regular para que coincida con una parte del contenido, si es necesario
  • Dirección URL del extremo remoto: dirección URL del extremo responsable de la generación del contenido
    • Utilice el protocolo HTTPS seguro si no está en la red local.
  • Encabezados de solicitud adicionales: Encabezados adicionales que se agregarán a la solicitud enviada al extremo remoto
    • Patrón: key=value
  • Tiempo de espera de solicitud: tiempo de espera de solicitud de host remoto en milisegundos
Independientemente de si decide implementar el flujo de comunicación dirigido por AEM o el flujo de Adobe I/O Runtime, debe definir una configuración de procesador de contenido remoto.
Esta configuración también debe definirse si elige utilizar un servidor Node.js personalizado.
Esta configuración aprovecha el procesador de contenido remoto, que tiene opciones adicionales de extensión y personalización disponibles.

Flujo de comunicación dirigido por AEM

Al utilizar SSR, el flujo de trabajo de interacción de componentes de SPA en AEM incluye una fase en la que el contenido inicial de la aplicación se genera en Adobe I/O Runtime.
  1. El navegador solicita el contenido de SSR a AEM.
  2. AEM publica el modelo en Adobe I/O Runtime.
  3. Adobe I/O Runtime devuelve el contenido generado.
  4. AEM proporciona el HTML devuelto por Adobe I/O Runtime a través de la plantilla HTL del componente de página de back-end.

Flujo de comunicación impulsado por el tiempo de ejecución de Adobe I/O

En la sección anterior se describe la implementación estándar y recomendada del procesamiento del lado del servidor con respecto a los SPA en AEM, donde AEM realiza el arranque y el servicio del contenido.
De forma alternativa, SSR se puede implementar para que Adobe I/O Runtime sea responsable del arranque, con lo que se invierte de forma efectiva el flujo de comunicación.
Ambos modelos son válidos y son compatibles con AEM. Sin embargo, hay que tener en cuenta las ventajas y desventajas de cada uno de ellos antes de aplicar un modelo determinado.
Bootstrap Ventajas Desventajas
mediante AEM
  • AEM administra las bibliotecas de inyección donde sea necesario
  • Solo es necesario mantener los recursos en AEM
  • Posiblemente no sea familiar para el desarrollador de SPA
mediante Adobe I/O Runtime
  • Más familiarizado con los desarrolladores de SPA
  • Los recursos de la biblioteca de clientes requeridos por la aplicación, como CSS y JavaScript, deberán estar disponibles para el desarrollador de AEM mediante la allowProxy propiedad
  • Los recursos deben sincronizarse entre AEM y Adobe I/O Runtime
  • Para habilitar la creación de SPA, puede ser necesario un servidor proxy para Adobe I/O Runtime

Planificación de SSR

Generalmente, solo una parte de una aplicación debe representarse en el servidor. El ejemplo común es que el contenido que se mostrará encima del pliegue en la carga inicial de la página se procesará en el servidor. Esto ahorra tiempo al enviar al cliente contenido ya procesado. A medida que el usuario interactúa con el SPA, el cliente procesa el contenido adicional.
A medida que considere implementar el procesamiento del lado del servidor para su SPA, debe revisar qué partes de la aplicación serán necesarias.

Desarrollo de un SPA mediante SSR

Los componentes de SPA pueden ser procesados por el cliente (en el navegador) o por el servidor. Cuando se procesa en el servidor, las propiedades del navegador, como el tamaño y la ubicación de la ventana, no están presentes. Por lo tanto, los componentes de la SPA deben ser isomórficos, sin suponer dónde se representarán.
Para aprovechar SSR, deberá implementar su código en AEM, así como en Adobe I/O Runtime, que es responsable del procesamiento en el servidor. La mayoría del código será el mismo, aunque las tareas específicas del servidor diferirán.

SSR para SPA en AEM

El SSR para SPA en AEM requiere Adobe I/O Runtime, que se llama para la representación del servidor de contenido de la aplicación. En el HTML de la aplicación, se llama a un recurso en tiempo de ejecución de Adobe I/O para procesar el contenido.
Al igual que AEM admite los marcos de SPA angulares y de reacción predeterminados, el procesamiento en el servidor también es compatible con las aplicaciones Angular y React. Consulte la documentación de NPM para conocer ambos marcos para obtener más detalles.
Para ver un ejemplo simplista, consulte la aplicación de Historial We.Retail. Procesa todo el lado del servidor de aplicaciones. Aunque este no es un ejemplo real, ilustra lo que se necesita para implementar la reforma del sector de la seguridad.
La aplicación de Historial We.Retail solo sirve para fines de demostración y, por tanto, utiliza Node.js como un ejemplo sencillo en lugar del tiempo de ejecución de Adobe I/O recomendado. Este ejemplo no debe utilizarse para ningún trabajo de proyecto.
Cualquier proyecto de AEM debería aprovechar el arquetipo del proyecto de AEM, que admite proyectos de SPA con React o Angular y aprovecha el SDK de SPA.

Uso de Node.js

Adobe I/O Runtime es la solución recomendada para implementar SSR para SPA en AEM.
En el caso de instancias de AEM in situ, también es posible implementar SSR mediante una instancia de Node.js personalizada de la misma manera que se describe anteriormente. Aunque Adobe lo admite, no se recomienda.
Node.js no es compatible con las instancias de AEM alojadas en Adobe.
Si SSR debe implementarse mediante Node.js, Adobe recomienda una instancia de Node.js independiente para cada entorno de AEM (autor, publicación, etapa, etc.).

Procesador de contenido remoto

La configuración del procesador de contenido remoto necesaria para utilizar SSR con el SPA en AEM se conecta a un servicio de procesamiento más generalizado que se puede ampliar y personalizar para satisfacer sus necesidades.

RemoteContentRenderingService

RemoteContentRenderingService es un servicio OSGi para recuperar contenido procesado en un servidor remoto, como por ejemplo, de Adobe I/O. El contenido enviado al servidor remoto se basa en el parámetro de solicitud pasado.
RemoteContentRenderingService se puede insertar mediante la inversión de dependencias en un modelo Sling personalizado o en un servlet cuando se requiera una manipulación de contenido adicional.
Este servicio lo utiliza internamente RemoteContentRendererRequestHandlerServlet .

RemoteContentRendererRequestHandlerServlet

El RemoteContentRendererRequestHandlerServlet se puede utilizar para configurar la solicitud mediante programación. DefaultRemoteContentRendererRequestHandlerImpl , la implementación predeterminada del controlador de solicitudes proporcionada, le permite crear varias configuraciones OSGi para asignar una ubicación en la estructura de contenido a un punto final remoto.
Para agregar un controlador de solicitud personalizado, implemente la RemoteContentRendererRequestHandler interfaz. Asegúrese de establecer la propiedad del Constants.SERVICE_RANKING componente en un entero mayor que 100, que es la clasificación del DefaultRemoteContentRendererRequestHandlerImpl .
@Component(immediate = true,
        service = RemoteContentRendererRequestHandler.class,
        property={
            Constants.SERVICE_RANKING +":Integer=1000"
        })
public class CustomRemoteContentRendererRequestHandlerImpl implements RemoteContentRendererRequestHandler {}

Configurar la configuración OSGi del controlador predeterminado

La configuración del controlador predeterminado debe configurarse como se describe en la sección Configuración del procesador de contenido remoto.

Uso del procesador de contenido remoto

Para que un servlet recupere y devuelva contenido que se puede insertar en la página:
  1. Asegúrese de que el servidor remoto sea accesible.
  2. Añada uno de los siguientes fragmentos en la plantilla HTL de un componente AEM.
  3. Opcionalmente, cree o modifique las configuraciones de OSGi.
  4. Explorar el contenido del sitio
Normalmente, la plantilla HTL de un componente de página es el destinatario principal de dicha función.
<sly data-sly-resource="${resource @ resourceType='cq/remote/content/renderer/request/handler'}" />

Requisitos

Los servlets aprovechan el Sling Model Exporter para serializar los datos del componente. De forma predeterminada, tanto com.adobe.cq.export.json.ContainerExporter como com.adobe.cq.export.json.ComponentExporter se admiten como adaptadores del modelo de Sling. Si es necesario, puede agregar clases que permitan adaptar la solicitud al uso RemoteContentRendererServlet y la implementación del RemoteContentRendererRequestHandler#getSlingModelAdapterClasses . Las clases adicionales deben ampliar el ComponentExporter .