Show Menu
ARGOMENTI×

Rendering SPA e lato server

SPA Editor è la soluzione consigliata per i progetti che richiedono il rendering lato client basato su SPA (ad esempio React o Angular).
Per utilizzare le funzioni di rendering lato server SPA come descritto in questo documento, è necessario AEM 6.5.1.0 o versione successiva.

Panoramica

Le applicazioni SPA (Single Page Applications) 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 i contenuti in primo piano e quindi sfruttando l'interazione con l'utente, riducendo al minimo la quantità di comunicazione necessaria tra il client e il server, rendendo l'app più reattiva.
Tuttavia, questo può comportare 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 parte del contenuto sul lato server. L’utilizzo del rendering lato server (SSR) può accelerare il caricamento iniziale della pagina e quindi passare al client un ulteriore rendering.

Quando utilizzare SSR

SSR non è richiesto per tutti i progetti. Sebbene AEM supporti completamente JS SSR per SPA, Adobe consiglia di non implementarlo sistematicamente per ogni progetto.
Quando si decide di implementare SSR è necessario prima stimare quale ulteriore complessità, sforzo e costo supplementare SSR rappresenta realisticamente per il progetto, inclusa la manutenzione a lungo termine. L'architettura SSR dovrebbe essere scelta solo quando il valore aggiunto supera chiaramente i costi stimati.
SSR di solito fornisce un certo valore quando esiste un chiaro "sì" a una delle seguenti domande:
  • SEO: Il servizio SSR è ancora effettivamente richiesto affinché il sito venga indicizzato correttamente dai motori di ricerca che generano traffico? Tenere presente che i principali crawler del motore di ricerca ora valutano JS.
  • Velocità pagina: La SSR offre un miglioramento misurabile della velocità negli ambienti reali e contribuisce all'esperienza complessiva dell'utente?
Solo quando almeno una di queste due domande riceve una risposta con un "sì" chiaro 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

Se sei certo che il progetto richiede l'implementazione di SSR , la soluzione consigliata da Adobe è l'utilizzo di Adobe I/O Runtime.
Per ulteriori informazioni su Adobe I/O Runtime, vedete
Nelle sezioni seguenti viene illustrato in che modo Adobe I/O Runtime può essere utilizzato per implementare SSR per l'SPA in due modelli diversi:
Adobe consiglia un’istanza runtime di I/O Adobe separata per ogni ambiente AEM (autore, pubblicazione, area di visualizzazione, ecc.).

Configurazione del rendering remoto

AEM deve sapere dove è possibile recuperare il contenuto sottoposto a rendering remoto. Indipendentemente dal modello che si sceglie di implementare per SSR, sarà necessario specificare ad AEM come accedere a questo servizio di rendering remoto.
Questa operazione viene eseguita tramite il servizio RemoteContentRenderer - Configuration Factory OSGi service . Cercate la stringa "RemoteContentRenderer" nella console Configurazione console Web all’indirizzo http://<host>:<port>/system/console/configMgr .
I campi seguenti sono disponibili per la configurazione:
  • Percorso contenuto - Espressione regolare per far corrispondere una parte del contenuto, se necessario
  • URL endpoint remoto - URL dell'endpoint responsabile della generazione del contenuto
    • Utilizzare il protocollo HTTPS protetto se non nella rete locale.
  • Intestazioni di richiesta aggiuntive - Intestazioni aggiuntive da aggiungere alla richiesta inviata all'endpoint remoto
    • Pattern: key=value
  • Timeout richiesta - Timeout richiesta host remoto in millisecondi
Indipendentemente dalla scelta di implementare il flusso di comunicazione basato su AEM o il flusso basato su runtime basato su Adobe I/O, è necessario definire una configurazione del renderer del contenuto remoto.
Questa configurazione deve essere definita anche se scegli di utilizzare un server Node.js personalizzato.
Questa configurazione sfrutta il modulo di rendering dei contenuti remoti, che offre ulteriori opzioni di estensione e personalizzazione.

Flusso di comunicazione basato su AEM

Quando si utilizza l’SSR, il flusso di lavoro di interazione dei componenti degli SPA in AEM include una fase in cui il contenuto iniziale dell’app viene generato in Adobe I/O Runtime.
  1. Il browser richiede il contenuto SSR da AEM.
  2. AEM inserisce il modello in Adobe I/O Runtime.
  3. Adobe I/O Runtime restituisce il contenuto generato.
  4. AEM fornisce l’HTML restituito da Adobe I/O Runtime tramite il modello HTL del componente della pagina di back-end.

Flusso di comunicazione basato su runtime Adobe I/O

La sezione precedente descrive l’implementazione standard e consigliata del rendering lato server per quanto riguarda gli SPA in AEM, dove AEM esegue l’avvio e la trasmissione 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 da AEM. Tuttavia, è opportuno considerare i vantaggi e gli svantaggi di ciascuno di essi prima di implementare un particolare modello.
Avvio Vantaggi Svantaggi
tramite AEM
  • AEM gestisce l'inserimento delle librerie laddove necessario
  • Le risorse devono essere mantenute solo su AEM
  • Potrebbe non essere familiare allo sviluppatore SPA
tramite Adobe I/O Runtime
  • Più familiare agli sviluppatori SPA
  • Le risorse Clientlib richieste dall'applicazione, come CSS e JavaScript, dovranno essere rese disponibili dallo sviluppatore AEM tramite la allowProxy proprietà
  • Le risorse devono essere sincronizzate tra AEM e Adobe I/O Runtime
  • Per abilitare la creazione dell'SPA, potrebbe essere necessario un server proxy per Adobe I/O Runtime

Pianificazione per SSR

In genere, è necessario eseguire il rendering solo di una parte dell'applicazione sul lato server. L’esempio comune è rappresentato dal contenuto che verrà visualizzato al di sopra della piega al caricamento iniziale della pagina, rappresentato sul lato server. Questo consente di risparmiare tempo distribuendo al client contenuti già sottoposti a rendering. Quando l'utente interagisce con l'app, il contenuto aggiuntivo viene rappresentato dal client.
Considerando l'implementazione del rendering lato server per l'app SPA, è necessario verificare quali parti dell'app saranno necessarie.

Sviluppo di una SPA con SSR

I componenti SPA possono essere sottoposti a rendering dal lato client (nel browser) o server. Sul lato server di cui è stato eseguito il rendering, le proprietà del browser, ad esempio la dimensione della finestra e la posizione, non sono presenti. Pertanto, i componenti SPA dovrebbero essere isomorfi, senza fare alcuna ipotesi su dove saranno sottoposti a rendering.
Per sfruttare SSR, è necessario implementare il codice in AEM e in Adobe I/O Runtime, responsabile per il rendering lato server. La maggior parte del codice sarà uguale, ma le attività specifiche del server saranno diverse.

SSR per SPA in AEM

SSR per gli SPA in AEM richiede Adobe I/O Runtime, che viene chiamato per il rendering del lato del server del contenuto dell'app. All'interno dell'HTL dell'app, per eseguire il rendering del contenuto viene chiamata una risorsa in Adobe I/O Runtime.
Come AEM supporta i framework Angular e React SPA out-of-the-box, anche il rendering lato server è supportato per le app Angular e React. Per ulteriori informazioni, consulta la documentazione di NPM per entrambi i framework.
Per un esempio semplicistico, consultate l'app aem-sample-we-retail-journalWe.Retail Journal. Viene eseguito il rendering dell'intero lato del server applicazione. Anche se non si tratta di un esempio reale, viene illustrato ciò che è necessario per implementare SSR.
L'app aem-sample-we-retail-journal We.Retail Journal è solo a scopo dimostrativo e pertanto utilizza Node.js come esempio semplice invece del runtime di I/O Adobe consigliato. Questo esempio non deve essere utilizzato per nessun progetto.
Qualsiasi progetto AEM deve sfruttare il tipo di archivio dei progetti AEM , che supporta i progetti SPA mediante React o Angular e sfrutta l’SDK SPA.

Utilizzo di Node.js

Adobe I/O Runtime è la soluzione consigliata per implementare SSR per SPA in AEM.
Per le istanze AEM in pre-installazione, è anche possibile implementare SSR utilizzando un'istanza Node.js personalizzata nello stesso modo descritto in precedenza. Anche se supportato da Adobe, non è consigliato.
Node.js non è supportato per le istanze AEM ospitate da Adobe.
Se SSR deve essere implementato tramite Node.js, Adobe consiglia un'istanza Node.js separata per ogni ambiente AEM (autore, pubblicazione, passaggio, ecc.).

Modulo di rendering contenuti remoto

La configurazione #remote-content-renderer-configuration Remote Content Renderer necessaria per utilizzare SSR con l’SPA in AEM è ora disponibile in un servizio di rendering più generalizzato che può essere esteso e personalizzato in base alle proprie esigenze.

RemoteContentRenderingService

RemoteContentRenderingService è un servizio OSGi per recuperare il contenuto 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 iniettato dall'inversione di dipendenza in un modello Sling personalizzato o servlet quando è richiesta ulteriore manipolazione del contenuto.
Questo servizio viene utilizzato internamente da RemoteContentRendererRequestHandlerServlet .

RemoteContentRendererRequestHandlerServlet

L' RemoteContentRendererRequestHandlerServlet opzione può essere utilizzata per impostare in modo programmatico la configurazione della richiesta. DefaultRemoteContentRendererRequestHandlerImpl , l'implementazione del gestore di richieste predefinito fornita, consente di creare più configurazioni OSGi per mappare una posizione nella struttura del contenuto a un endpoint remoto.
Per aggiungere un gestore di richieste personalizzato, implementate l' RemoteContentRendererRequestHandler interfaccia. Accertatevi di impostare la proprietà del Constants.SERVICE_RANKING componente su un numero intero superiore a 100, che corrisponde alla classifica del 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

La configurazione del gestore predefinito deve essere configurata come descritto nella sezione Configurazione del modulo di rendering dei contenuti remoti.

Utilizzo del modulo di rendering dei contenuti remoti

Per ottenere un servlet fetch e restituire il contenuto che può essere inserito nella pagina:
  1. Verificare che il server remoto sia accessibile.
  2. Aggiungete uno dei seguenti snippet al modello HTL di un componente AEM.
  3. Facoltativamente, potete creare o modificare le configurazioni OSGi.
  4. Sfogliare il contenuto del sito
In genere, il modello HTL di un componente di pagina è il destinatario principale di tale funzione.
<sly data-sly-resource="${resource @ resourceType='cq/remote/content/renderer/request/handler'}" />

Requisiti

I servlet sfruttano Sling Model Exporter per serializzare i dati dei componenti. Per impostazione predefinita, sia i modelli com.adobe.cq.export.json.ContainerExporter che com.adobe.cq.export.json.ComponentExporter sono supportati come adattatori Sling Model. Se necessario, è possibile aggiungere classi che la richiesta deve essere adattata all'utilizzo RemoteContentRendererServlet e all'implementazione di RemoteContentRendererRequestHandler#getSlingModelAdapterClasses . Le classi aggiuntive devono estendere l' ComponentExporter .