Rendering lato server e SPA spa-and-server-side-rendering

Panoramica overview

Le applicazioni a pagina singola (SPA) possono offrire all’utente un’esperienza ricca e dinamica che reagisce e si comporta in modo familiare, spesso come un’applicazione nativa. Ciò si ottiene affidandosi al client per caricare il contenuto in primo piano e poi fare il pesante sollevamento dell'interazione dell'utente riducendo al minimo la quantità di comunicazione necessaria tra client e server, rendendo l’app più reattiva.

Tuttavia, questo può portare a tempi di caricamento iniziali più lunghi, soprattutto se l’SPA è grande e ricco di contenuti. Per ottimizzare i tempi di caricamento, è possibile eseguire il rendering di alcuni contenuti lato server. L’utilizzo del rendering lato server (SSR) può accelerare il caricamento iniziale della pagina e quindi trasmettere un ulteriore rendering al client.

Quando utilizzare SSR when-to-use-ssr

SSR non è richiesto per tutti i progetti. Sebbene l’AEM supporti completamente la SSR JS per l’SPA, l’Adobe sconsiglia di attuarla sistematicamente per ogni progetto.

Quando decidi di implementare SSR, devi innanzitutto stimare quali ulteriori complessità, sforzi e costi aggiuntivi SSR rappresentano in modo realistico per il progetto, inclusa la manutenzione a lungo termine. Un’architettura SSR dovrebbe essere scelta solo quando il valore aggiunto supera chiaramente i costi stimati.

In genere, SSR fornisce un valore quando è presente un "sì" chiaro a una delle seguenti domande:

Solo quando ad almeno una di queste due domande viene risposto con un chiaro "sì" per il progetto, Adobe consiglia di implementare SSR. Le sezioni seguenti descrivono come eseguire questa operazione utilizzando Adobe I/O Runtime.

Adobe I/O Runtime adobe-i-o-runtime

Se sono certi che il tuo progetto richieda l'implementazione di SSR, la soluzione consigliata da Adobe è l’utilizzo di Adobe I/O Runtime.

Per ulteriori informazioni su Adobe I/O Runtime, vedi:

Le sezioni seguenti descrivono come Adobe I/O Runtime può essere utilizzato per implementare SSR per l’SPA in due modelli diversi:

Configurazione Remote Renderer remote-renderer-configuration

L’AEM deve sapere dove è possibile recuperare i contenuti renderizzati in remoto. Indipendentemente da il modello che si sceglie di implementare per SSR,, è necessario specificare a AEM come accedere a questo servizio di rendering remoto.

Questa operazione viene eseguita tramite RemoteContentRenderer - Servizio OSGi di Configuration Factory. Cerca la stringa "RemoteContentRenderer" nella console di configurazione della console Web all'indirizzo http://<host>:<port>/system/console/configMgr.

Per la configurazione sono disponibili i seguenti campi:

Flusso di comunicazione basato sull’AEM aem-driven-communication-flow

Quando si utilizza SSR, il flusso di lavoro di interazione dei componenti dell’SPA nell’AEM include una fase in cui il contenuto iniziale dell’app viene generato su Adobe I/O Runtime.

Flusso di comunicazione basato su Adobe I/O Runtime adobe-i-o-runtime-driven-communication-flow

La sezione precedente descrive l’implementazione standard e consigliata del rendering lato server per quanto riguarda l’SPA nell’AEM, in cui l’AEM esegue il bootstrapping e la distribuzione dei contenuti.

In alternativa, SSR può essere implementato in modo che Adobe I/O Runtime sia responsabile dell'avvio, invertendo efficacemente il flusso di comunicazione.

Entrambi i modelli sono validi e supportati dall’AEM. Tuttavia, si dovrebbero considerare i vantaggi e gli svantaggi di ciascuno prima di implementare un particolare modello.

Pianificazione per SSR planning-for-ssr

È necessario eseguire il rendering lato server solo di una parte dell'applicazione. L’esempio comune è il contenuto visualizzato sopra la piega al caricamento iniziale della pagina, di cui viene eseguito il rendering sul lato server. In questo modo si risparmia tempo distribuendo al client contenuti già sottoposti a rendering. Quando l’utente interagisce con l’SPA, il contenuto aggiuntivo viene riprodotto dal client.

Se stai valutando l’implementazione del rendering lato server per l’SPA, controlla quali parti dell’app sono necessarie.

Sviluppo di un SPA utilizzando la SSR developing-an-spa-using-ssr

Il rendering dei componenti SPA poteva essere eseguito dal client (nel browser) o dal lato server. Quando viene eseguito il rendering lato server, le proprietà del browser come le dimensioni della finestra e la posizione non sono presenti. Pertanto, i componenti dell’SPA devono essere isomorfi, senza presupporre dove saranno resi.

Per utilizzare SSR, distribuisci il codice in AEM e su Adobe I/O Runtime, responsabile del rendering lato server. La maggior parte del codice sarà lo stesso, tuttavia, le attività specifiche del server saranno diverse.

SSR per l’SPA nell’AEM ssr-for-spas-in-aem

La SSR per l’SPA nell’AEM richiede Adobe I/O Runtime, che è chiamato per il rendering del lato server del contenuto dell’app. All’interno dell’HTL dell’app, viene chiamata una risorsa su Adobe I/O Runtime per eseguire il rendering del contenuto.

Proprio come l’AEM supporta i framework SPA Angular e React pronti all’uso, è supportato anche il rendering lato server, ad Angular per le app React. Per ulteriori dettagli, consulta la documentazione NPM per entrambi i framework.

Per un esempio semplicistico, vedi App We.Retail Journal. Viene eseguito il rendering dell'intero lato server applicazioni. Anche se non si tratta di un esempio reale, questo illustra ciò che è necessario per implementare la SSR.

Utilizzo di Node.js using-node-js

Adobe I/O Runtime è la soluzione consigliata per l’implementazione della SSR per l’SPA nell’AEM.

Per le istanze AEM locali, è anche possibile implementare SSR utilizzando un’istanza Node.js personalizzata nello stesso modo descritto in precedenza. Sebbene supportato da Adobe, non è consigliato.

Rendering contenuto remoto remote-content-renderer

Il Configurazione rendering contenuto remoto che è necessario per utilizzare SSR con il tuo SPA in AEM si inserisce in un servizio di rendering più generalizzato che può essere esteso e personalizzato per soddisfare le tue esigenze.

Servizio RemoteContentRendering remotecontentrenderingservice

RemoteContentRenderingService è un servizio OSGi per recuperare il contenuto di cui è stato eseguito il rendering su un server remoto, ad esempio da Adobe I/O. Il contenuto inviato al server remoto si basa sul parametro di richiesta passato.

RemoteContentRenderingService può essere inserito tramite inversione delle dipendenze in un modello Sling personalizzato o in un servlet quando è necessaria un’ulteriore manipolazione del contenuto.

Questo servizio è utilizzato internamente da RemoteContentRendererRequestHandlerServlet.

RemoteContentRendererRequestHandlerServlet remotecontentrendererrequesthandlerservlet

Il RemoteContentRendererRequestHandlerServlet può essere utilizzato per impostare a livello di programmazione la configurazione della richiesta. DefaultRemoteContentRendererRequestHandlerImpl, l’implementazione predefinita del gestore di richieste fornita, ti consente di creare più configurazioni OSGi per mappare una posizione nella struttura del contenuto su un endpoint remoto.

Per aggiungere un gestore di richieste personalizzato, implementa RemoteContentRendererRequestHandler di rete. Assicurarsi di impostare Constants.SERVICE_RANKING proprietà del componente a un numero intero maggiore di 100, che corrisponde alla classificazione DefaultRemoteContentRendererRequestHandlerImpl.

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

Configurare la configurazione OSGi del gestore predefinito configure-default-handler

La configurazione del gestore predefinito deve essere configurata come descritto nella sezione Configurazione rendering contenuto remoto.

Utilizzo di Remote Content Renderer usage

Per recuperare un servlet e restituire parte del contenuto che può essere inserito nella pagina:

Di solito, il modello HTL di un componente pagina è il destinatario principale di tale funzione.

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

Requisiti requirements

I servlet utilizzano Sling Model Exporter per serializzare i dati del componente. Per impostazione predefinita, entrambe le opzioni com.adobe.cq.export.json.ContainerExporter e com.adobe.cq.export.json.ComponentExporter sono supportati come adattatori del modello Sling. Se necessario, puoi aggiungere le classi a cui la richiesta deve essere adattata utilizzando RemoteContentRendererServlet e l'implementazione RemoteContentRendererRequestHandler#getSlingModelAdapterClasses. Le classi aggiuntive devono estendere ComponentExporter.