Renderização de SPA e do servidor spa-and-server-side-rendering

Visão geral overview

Aplicativos de página única (SPA) podem oferecer ao usuário experiências ricas e dinâmicas que reagem e se comportam de formas familiares, normalmente como aplicativos nativos. Isso é feito contando com o cliente para carregar o conteúdo antecipadamente e depois fazer o pesado levantamento da manipulação da interação do usuário e, assim, minimizar a quantidade de comunicação necessária entre o cliente e o servidor, tornando o aplicativo mais reativo.

No entanto, isso pode levar a tempos de carregamento iniciais mais longos, especialmente se o SPA for grande e rico em seu conteúdo. Para otimizar os tempos de carregamento, parte do conteúdo pode ser renderizado no lado do servidor. O uso da renderização do lado do servidor (SSR) pode acelerar a carga inicial da página e, em seguida, transmitir mais renderização para o cliente.

Quando utilizar o SSR when-to-use-ssr

A RSS não é necessária em todos os projetos. Embora o AEM seja totalmente compatível com o JS SSR para SPA, o Adobe não recomenda implementá-lo sistematicamente para cada projeto.

Ao decidir implementar a SSR, você deve primeiro estimar qual complexidade adicional, esforço e custo adicional a SSR representa realisticamente para o projeto, incluindo a manutenção de longo prazo. Uma arquitetura RSS só deve ser escolhida quando o valor acrescentado exceder claramente os custos estimados.

O SSR geralmente fornece algum valor quando há um claro "sim" para qualquer uma das seguintes perguntas:

Somente quando uma dessas duas perguntas for respondida com um "sim" claro para o seu projeto o Adobe recomenda a implementação do SSR. As seções a seguir descrevem como fazer isso usando o Adobe I/O Runtime.

Adobe I/O Runtime adobe-io-runtime

Se você confiante de que o projeto requer a implementação do SSR, Adobe recomendado é usar a solução Adobe I/O Runtime.

Para obter mais informações sobre o Adobe I/O Runtime, consulte

As seções a seguir detalham como o Adobe I/O Runtime pode ser usado para implementar o SSR para seu SPA em dois modelos diferentes:

Configuração do renderizador de conteúdo remoto remote-content-renderer-configuration

AEM deve saber onde o conteúdo renderizado remotamente pode ser recuperado. Independente de qual modelo você escolhe implementar para SSR, será necessário especificar para AEM como acessar esse serviço de renderização remota.

Isso é feito por meio da variável RemoteContentRenderer - Fábrica de Configuração Serviço OSGi. Procure a string "RemoteContentRenderer" no console Configuração do Console da Web em http://<host>:<port>/system/console/configMgr.

Os seguintes campos estão disponíveis para a configuração:

Fluxo de comunicação orientado por AEM aem-driven-communication-flow

Ao usar o SSR, a variável fluxo de trabalho de interação do componente O SPA no AEM inclui uma fase na qual o conteúdo inicial do aplicativo é gerado pelo Adobe I/O Runtime.

Fluxo de comunicação orientado pela Adobe I/O Runtime adobe-io-driven-communication-flow

A seção Fluxo de comunicação orientado por AEM descreve a implementação padrão e recomendada da renderização do lado do servidor no que diz respeito ao SPA no AEM, onde o AEM executa o bootstrapping e o fornecimento de conteúdo.

Como alternativa, o SSR pode ser implementado para que a Adobe I/O Runtime seja responsável pelo bootstrapping, revertendo efetivamente o fluxo de comunicação.

Ambos os modelos são válidos e aceitos pela AEM. No entanto, deve-se considerar as vantagens e desvantagens de cada um antes de implementar um modelo específico.

Planejamento para SSR planning-for-ssr

Geralmente, apenas parte de um aplicativo precisa ser renderizada no lado do servidor. O exemplo comum é o conteúdo que será exibido acima da dobra no carregamento inicial da página que precisa ser renderizado no lado do servidor. Isso economiza tempo fornecendo ao cliente conteúdo já renderizado. Conforme o usuário interage com a SPA, o conteúdo adicional é renderizado pelo cliente.

Ao considerar a implementação da renderização do lado do servidor para o seu SPA, é necessário revisar quais partes do aplicativo serão necessárias para SSR.

Desenvolvimento de um SPA usando o SSR developing-an-spa-using-ssr

SPA componentes podem ser renderizados pelo cliente (no navegador) ou pelo lado do servidor. Quando renderizado no lado do servidor, as propriedades do navegador, como tamanho e local da janela, não estarão presentes. Por conseguinte, os componentes SPA devem ser isóficos, não assumindo qualquer hipótese quanto ao local em que serão apresentados.

Para usar o SSR, será necessário implantar seu código no AEM e no Adobe I/O Runtime, que é responsável pela renderização do lado do servidor. A maioria do código será o mesmo, no entanto, as tarefas específicas do servidor serão diferentes.

SSR para SPA em AEM ssr-for-spas-in-aem

O SSR para SPA no AEM requer o Adobe I/O Runtime, que é chamado para a renderização do lado do servidor de conteúdo do aplicativo. No HTL do aplicativo, um recurso no Adobe I/O Runtime é chamado para renderizar o conteúdo.

Assim como o AEM suporta as estruturas Angular e React SPA prontas para uso, a renderização do lado do servidor também é compatível com os aplicativos Angular e React. Para obter mais detalhes, consulte a documentação do NPM para ambas as estruturas.

Para obter um exemplo simplista, consulte o Aplicativo de diário We.Retail. Ele renderiza todo o lado do servidor de aplicativos. Embora este não seja um exemplo real, ele ilustra o que é necessário para implementar o SSR.

Uso de Node.js using-node-js

O Adobe I/O Runtime é a solução recomendada para implementar o SSR para SPA no AEM.

Para instâncias de AEM no local, também é possível implementar o SSR usando uma instância Node.js personalizada da mesma forma como descrito acima. Embora isso seja suportado pelo Adobe, não é recomendado.

Node.js não é compatível com instâncias de AEM hospedadas por Adobe.

Renderizador de conteúdo remoto remote-content-renderer

O Configuração do renderizador de conteúdo remoto que é necessário para usar o SSR com seu SPA em AEM toques em um serviço de renderização mais generalizado que pode ser estendido e personalizado para atender às suas necessidades.

RemoteContentRenderingService remotecontentrenderingservice

RemoteContentRenderingService é um serviço OSGi para recuperar conteúdo renderizado em um servidor remoto, como a partir do Adobe I/O. O conteúdo enviado para o servidor remoto é baseado no parâmetro de solicitação transmitido.

RemoteContentRenderingService pode ser inserido por inversão de dependência em um modelo Sling personalizado ou servlet, quando for necessária manipulação de conteúdo adicional.

Esse serviço é usado internamente pela variável RemoteContentRendererRequestHandlerServlet.

RemoteContentRendererRequestHandlerServlet remotecontentrendererrequesthandlerservlet

O RemoteContentRendererRequestHandlerServlet pode ser usada para definir programaticamente a configuração da solicitação. DefaultRemoteContentRendererRequestHandlerImpl, a implementação do manipulador de solicitação padrão fornecida permite criar várias configurações de OSGi para mapear um local na estrutura de conteúdo a um terminal remoto.

Para adicionar um Manipulador de solicitação personalizado, implemente o RemoteContentRendererRequestHandler interface. Certifique-se de definir a variável Constants.SERVICE_RANKING propriedade do componente para um número inteiro superior a 100, que é a classificação da variável DefaultRemoteContentRendererRequestHandlerImpl.

@Component(immediate = true,
        service = RemoteContentRendererRequestHandler.class,
        property={
            Constants.SERVICE_RANKING +":Integer=1000"
        })
public class CustomRemoteContentRendererRequestHandlerImpl implements RemoteContentRendererRequestHandler {}

Configurar a configuração OSGi do manipulador padrão configure-default-handler

A configuração do manipulador padrão deve ser configurada conforme descrito na seção Configuração do renderizador de conteúdo remoto.

Uso do Renderizador de Conteúdo Remoto usage

Para ter uma busca de servlet e retornar algum conteúdo que possa ser inserido na página:

Normalmente, o modelo HTL de um componente de página é o principal recipient de tal recurso.

<sly data-sly-resource="${resource @ resourceType='cq/remote/content/renderer/request/handler'}" />

Requisitos requirements

Os servlets usam o Exportador de Modelo do Sling para serializar os dados do componente. Por padrão, ambas as variáveis com.adobe.cq.export.json.ContainerExporter e com.adobe.cq.export.json.ComponentExporter são compatíveis como adaptadores do Sling Model. Se necessário, você pode adicionar classes para as quais a solicitação deve ser adaptada ao uso da variável RemoteContentRendererServlet e a execução RemoteContentRendererRequestHandler#getSlingModelAdapterClasses. As classes adicionais devem estender o ComponentExporter.