O Editor de SPA é a solução recomendada para projetos que exigem renderização do cliente baseada em SPA estrutura (por exemplo, Reagir ou Angular).
AEM 6.5.1.0 ou posterior é necessário para usar os recursos de renderização do lado do servidor SPA conforme descrito neste documento.
Aplicativos de página única (SPA) podem oferta ao usuário uma experiência rica e dinâmica que reage e se comporta de maneiras familiares, normalmente 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 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.
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:
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.
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
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.).
AEM deve saber onde o conteúdo renderizado remotamente pode ser recuperado. Independentemente de qual modelo você escolher implementar para SSR, você precisará especificar para AEM como acessar esse serviço de renderização remota.
Isso é feito por meio do 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:
key=value
Independentemente de você optar por implementar o fluxo de comunicação orientado por AEM ou o fluxo controlado pela Adobe I/O Runtime, você deve definir uma configuração de renderizador de conteúdo remoto.
Essa configuração também deve ser definida se você optar por usar um servidor Nó.js personalizado.
Essa configuração aproveita o Remote Content Renderer, que tem opções adicionais de extensão e personalização disponíveis.
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 no Adobe I/O Runtime.
O navegador solicita o conteúdo SSR da AEM.
AEM publica o modelo no Adobe I/O Runtime.
A Adobe I/O Runtime retorna o conteúdo gerado.
AEM serve o HTML retornado pela Adobe I/O Runtime por meio do modelo HTL do componente de página de backend.
A seção anterior 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 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 |
|
|
via Adobe I/O Runtime |
|
|
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 a implementação da renderização do lado do servidor para seu SPA, é necessário verificar quais partes do aplicativo serão necessárias.
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.
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.
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.
O Aplicativo de Journal We.Retail é apenas para fins de demonstração e, portanto, usa Node.js como um exemplo simples em vez do Adobe I/O Runtime recomendado. Este exemplo não deve ser usado para nenhum trabalho de projeto.
Qualquer projeto AEM deve aproveitar o AEM Project Archetype, que suporta projetos SPA usando React ou Angular e aproveita o SPA SDK.
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.
Se o SSR precisar ser implementado via Node.js, o Adobe recomenda uma instância diferente de Node.js para cada ambiente AEM (autor, publicação, estágio etc.).
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
é 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.
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 {}
A configuração do manipulador padrão deve ser configurada conforme descrito na seção Configuração do Remote Content Renderer.
Para obter um servlet e retornar algum conteúdo que possa ser inserido na página:
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'}" />
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
.