Show Menu
TÓPICOS×

Renderização do SPA e do servidor

Aplicativos de página única (SPAs) podem oferta ao usuário uma experiência rica e dinâmica que reage e se comporta de maneiras familiares, geralmente como um aplicativo nativo. 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 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 total a JS SSR para SPA, o Adobe não recomenda implementá-lo 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: O SSR ainda é necessário 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 pelo menos 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 da SSR , a solução Adobe recomendada é usar a Adobe I/O Runtime
Para obter mais informações sobre o Adobe I/O Runtime, consulte
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:
O Adobe recomenda uma instância do Adobe I/O Runtime separada para cada ambiente AEM (autor, publicação, estágio etc.).

Configuração do Renderizador Remoto

AEM deve saber onde o conteúdo renderizado remotamente pode ser recuperado. Independentemente do modelo que você escolher implementar para SSR, será necessário especificar para AEM como acessar esse serviço de renderização remota.
Isso é feito via RemoteContentRenderer - serviço OSGi de fábrica de configuração. 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
Independentemente de se optar por implementar o fluxo de comunicação orientado por AEM ou o fluxo controlado por Adobe I/O Runtime, é necessário definir uma configuração de renderizador de conteúdo remoto.
Essa configuração aproveita o Remote Content Renderer, que tem opções adicionais de extensão e personalização disponíveis.

Fluxo de comunicação orientado por AEM

Ao usar o SSR, o fluxo de trabalho de interação de componentes dos SPAs no AEM inclui uma fase na qual o conteúdo inicial do aplicativo é gerado no 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 anterior descreve a implementação padrão e recomendada da renderização do lado do servidor em relação aos SPAs no AEM, onde o AEM executa o carregamento automático 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 quando necessário
  • Os recursos só precisam ser mantidos em AEM
  • Possivelmente estranho para o desenvolvedor SPA
via Adobe I/O Runtime
  • Mais familiar para desenvolvedores de SPA
  • Os recursos clientlib exigidos pelo aplicativo, como CSS e JavaScript, precisarão ser disponibilizados pelo desenvolvedor AEM por meio da allowProxy propriedade
  • Os recursos devem ser sincronizados entre o AEM e o 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 é 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 SPA, é necessário verificar quais partes do aplicativo serão necessárias.

Desenvolvimento de um SPA usando SSR

Os componentes SPA 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 do 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 SPAs em AEM

A SSR para SPAs 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 SPA Angular e React prontas, a renderização no lado do servidor também é compatível com aplicativos Angular e React. Consulte a documentação do NPM para obter mais detalhes sobre ambas as estruturas.

Renderizador de conteúdo remoto

A Configuração do renderizador de conteúdo remoto necessária para usar o SSR com seu SPA AEM toca 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 de E/S de Adobe. 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.
Esse 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 RemoteContentRendererRequestHandler interface. Certifique-se de definir a propriedade do Constants.SERVICE_RANKING componente para um número inteiro superior a 100, que é a classificação do 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 renderizador de conteúdo remoto.

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, é possível adicionar classes para as quais a solicitação deve ser adaptada para usar o RemoteContentRendererServlet e implementar o RemoteContentRendererRequestHandler#getSlingModelAdapterClasses . As classes adicionais devem estender o ComponentExporter .