Renderização do SPA e do servidor

Visão geral

Aplicativos de página única (SPA) podem oferta ao usuário de experiências ricas e dinâmicas que reagem e se comportam de maneiras familiares, normalmente como aplicativos nativos. Isso é feito contando com o cliente para carregar o conteúdo antecipadamente e, em seguida, fazer um pesado levantamento da manipulação da interação do usuário, minimizando assim 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 o tempo de carregamento, parte do conteúdo pode ser renderizada no lado do servidor. O uso da renderização no lado do servidor (SSR) pode acelerar a carga inicial da página e passar a renderização para o cliente.

Quando usar o SSR

A SSR não é necessária em todos os projetos. Embora AEM suporte totalmente a JS SSR para SPA, a Adobe não recomenda implementá-la sistematicamente para cada projeto.

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

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

• SEO: a SSR ainda é necessária para que seu site seja indexado corretamente pelos mecanismos de pesquisa que trazem tráfego? Lembre-se de que os principais rastreadores de mecanismo de pesquisa agora avaliam o JS.
• Velocidade da página: a SSR fornece uma melhoria mensurável da velocidade em ambientes reais e adiciona à experiência geral do usuário?

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

Adobe I/O Runtime

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

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

• https://www.adobe.io/apis/experienceplatform/runtime.html - para obter uma visão geral do serviço
• https://www.adobe.io/apis/experienceplatform/runtime/docs.html - para obter a documentação detalhada sobre a plataforma

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

• Fluxo de comunicação orientado por AEM
• Fluxo de comunicação direcionado ao tempo de execução da Adobe I/O

Configuração remota do renderizador de conteúdo

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

Isso é feito por meio do serviço RemoteContentRenderer - Configuration Fatory 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:

• Padrão do caminho do conteúdo - expressão regular para corresponder a uma parte do conteúdo, se necessário
• URL de ponto de extremidade remoto - URL do ponto de extremidade responsável pela geração do conteúdo
  • Use o protocolo HTTPS protegido se não estiver na rede local.
• Cabeçalhos de solicitação adicionais - Cabeçalhos adicionais a serem adicionados à solicitação enviada ao terminal remoto
  • Padrão: key=value
• Tempo limite da solicitação - Tempo limite da solicitação de host remoto em milissegundos

Fluxo de comunicação orientado por AEM

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

1. O navegador solicita o conteúdo SSR da AEM.
2. AEM publica o modelo no Adobe I/O Runtime.
3. A Adobe I/O Runtime retorna o conteúdo gerado
4. AEM serve o HTML retornado pela Adobe I/O Runtime por meio do modelo HTL do componente de página de backend.

Fluxo de comunicação orientado pela Adobe I/O Runtime

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 em relação ao SPA no AEM, onde AEM executa o carregamento de inicialização e a disponibilização de conteúdo.

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

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

Bootstrapping	Vantagens	Desvantagens
via AEM	AEM gerencia bibliotecas injetáveis onde necessário Os recursos só precisam ser mantidos no AEM	Possivelmente estranho ao desenvolvedor SPA
via Adobe I/O Runtime	Mais familiar para desenvolvedores SPA	Os recursos clientlib exigidos pelo aplicativo, como CSS e JavaScript, precisarão ser disponibilizados pelo desenvolvedor AEM por meio da propriedade allowProxy Os recursos devem ser sincronizados entre AEM e Adobe I/O Runtime Para habilitar a criação do SPA, pode ser necessário um servidor proxy para Adobe I/O Runtime

Planejamento para 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 na carga inicial da página que precisa ser renderizada no lado do servidor. Isso economiza tempo fornecendo ao cliente conteúdo já renderizado. Conforme o usuário interage com o SPA, o conteúdo adicional é renderizado pelo cliente.

Ao considerar implementar a renderização do lado do servidor para o seu SPA, é necessário revisar quais partes do aplicativo ele exigirá SSR.

Desenvolvimento de um SPA usando o SSR

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

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

SSR para SPA em AEM

A SSR para SPA em AEM exige a Adobe I/O Runtime, que é chamada 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.

Da mesma forma que o AEM suporta as estruturas Angular e React SPA predefinidas, a renderização do lado do servidor também é suportada para aplicativos Angular e React. Consulte a documentação do NPM para obter mais detalhes sobre ambas as estruturas.

• Reagir: https://github.com/adobe/aem-sample-we-retail-journal/blob/master/react-app/DEVELOPMENT.md#enabling-the-server-side-rendering-using-the-aem-page-component
• Angular: https://github.com/adobe/aem-sample-we-retail-journal/blob/master/react-app/DEVELOPMENT.md#enabling-the-server-side-rendering-using-the-aem-page-component

Para obter um exemplo simplista, consulte o aplicativo de Journal 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 a SSR.

Usando Node.js

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

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

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

Renderizador de conteúdo remoto

A Configuração do Remote Content Renderer necessária para usar o SSR com seu SPA em AEM se encaixa em um serviço de renderização mais generalizado que pode ser estendido e personalizado para atender às suas necessidades.

RemoteContentRenderingService

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

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.

Este serviço é usado internamente pelo RemoteContentRendererRequestHandlerServlet.

RemoteContentRendererRequestHandlerServlet

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

Para adicionar um Manipulador de solicitações personalizado, implemente a interface RemoteContentRendererRequestHandler. Certifique-se de definir a propriedade do componente Constants.SERVICE_RANKING como um número inteiro maior que 100, que é a classificação de 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

A configuração do manipulador padrão deve ser configurada conforme descrito na seção Configuração do Remote Content Renderer.

Uso do Renderizador de Conteúdo Remoto

Para obter um servlet e retornar algum conteúdo que possa ser inserido na página:

1. Verifique se o servidor remoto está acessível.
2. Adicione um dos seguintes trechos ao modelo HTL de um componente AEM.
3. Como opção, crie ou modifique as configurações do OSGi.
4. Procurar o conteúdo do site

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

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

Requisitos

Os servlets aproveitam o Exportador do Modelo Sling para serializar os dados do componente. Por padrão, os adaptadores com.adobe.cq.export.json.ContainerExporter e com.adobe.cq.export.json.ComponentExporter são suportados como Sling Model. Se necessário, você pode adicionar classes para as quais a solicitação deve ser adaptada usando RemoteContentRendererServlet e implementando RemoteContentRendererRequestHandler#getSlingModelAdapterClasses. As classes adicionais devem estender ComponentExporter.