SPA- och serveråtergivning

Senast uppdaterad: 4 maj 2023

Skapat för:

  • Developer
CAUTION
AEM 6.4 har nått slutet på den utökade supporten och denna dokumentation är inte längre uppdaterad. Mer information finns i teknisk supportperiod. Hitta de versioner som stöds här.
NOTE
Funktionen SPA (Single-Page Application) Editor kräver AEM 6.4 Service Pack 2 eller nyare.
SPA Editor är den rekommenderade lösningen för projekt som kräver SPA ramverksbaserad återgivning på klientsidan (t.ex. Reaktion eller Angular).
NOTE
AEM 6.4.5.0 eller senare krävs för att använda de återgivningsfunktioner på SPA serversidan som beskrivs i det här dokumentet.

Översikt

Applikationer för en enda sida (SPA) kan ge användaren en rik, dynamisk upplevelse som reagerar och beter sig på välbekanta sätt, ofta precis som med andra applikationer. Detta uppnås genom att klienten förlitar sig på att läsa in innehållet framtill och sedan göra den tunga hanteringen av användarinteraktionen och på så sätt minimera mängden kommunikation som krävs mellan klienten och servern, vilket gör appen mer reaktiv.

Detta kan dock leda till längre inledande inläsningstider, särskilt om SPA är stor och har mycket innehåll. För att optimera inläsningstiden kan en del av innehållet återges på serversidan. Serversidorendering (SSR) kan snabba upp den initiala inläsningen av sidan och sedan överföra ytterligare återgivning till klienten.

När SSR ska användas

SSR krävs inte för alla projekt. Även om AEM stöder JS SSR fullt ut för SPA rekommenderar Adobe inte att man implementerar det systematiskt för varje projekt.

När du beslutar dig för att implementera SSR måste du först uppskatta vilken ytterligare komplexitet, insats och kostnad som SSR innebär på ett realistiskt sätt för projektet, inklusive det långsiktiga underhållet. En SSR-arkitektur bör endast väljas när mervärdet klart överstiger de uppskattade kostnaderna.

SSR ger vanligtvis ett visst värde när det finns ett tydligt"ja" till någon av följande frågor:

  • SEO: Krävs det fortfarande SSR för att webbplatsen ska kunna indexeras korrekt av sökmotorer som genererar trafik? Kom ihåg att de viktigaste sökmotorcrawlarna nu utvärderar JS.
  • Sidhastighet: Ger SSR en mätbar hastighetsförbättring i realtidsmiljöer och ökar den övergripande användarupplevelsen?

Endast när minst en av dessa två frågor besvaras med ett tydligt"ja" för ditt projekt rekommenderar Adobe att SSR implementeras. I följande avsnitt beskrivs hur du gör detta med Adobe I/O Runtime.

Adobe I/O Runtime

Om du du är säker på att ditt projekt kräver SSR, rekommenderas Adobe att använda Adobe I/O Runtime.

Mer information om Adobe I/O Runtime finns på

I följande avsnitt beskrivs hur Adobe I/O Runtime kan användas för att implementera SSR för dina SPA i två olika modeller:

NOTE
Adobe rekommenderar en separat Adobe I/O Runtime-arbetsyta per miljö (scen, prod, testning osv.). Detta möjliggör typiska mönster för systemutvecklingens livscykel (SDLC) med olika versioner av ett enda program som distribueras till olika miljöer. Se dokumentet CI/CD för Project App Builder-program för mer information.
En separat arbetsyta behövs inte per instans (författare, publicering) såvida det inte finns skillnader i körtidsimplementeringen per instanstyp.

Konfiguration av fjärrinnehållsrenderare

AEM måste veta var det fjärråtergivna innehållet kan hämtas. Oavsett vilken modell du väljer att implementera för SSRmåste du ange AEM hur du får åtkomst till den här fjärrrenderingstjänsten.

Detta görs via RemoteContentRenderer - konfigurationsfabrik OSGi-tjänst. Sök efter strängen RemoteContentRenderer i webbkonsolens konfigurationskonsol på http://<host>:<port>/system/console/configMgr.

Följande fält är tillgängliga för konfigurationen:

  • Mönster för innehållsbana - Reguljära uttryck för att matcha en del av innehållet, om det behövs
  • URL för fjärrslutpunkt - URL för slutpunkten som ansvarar för att generera innehållet
    • Använd det säkra HTTPS-protokollet om det inte finns i det lokala nätverket.
  • Ytterligare begäranderubriker - Ytterligare rubriker som ska läggas till i begäran som skickas till fjärrslutpunkten
    • Mönster: key=value
  • Timeout för begäran - Timeout för fjärrvärdbegäran i millisekunder
NOTE
Oavsett om du väljer att implementera AEM kommunikationsflöde eller Adobe I/O Runtime-styrt flödemåste du definiera en fjärrkonfiguration för innehållsåtergivning.
Den här konfigurationen måste också definieras om du väljer att använd en anpassad Node.js-server.
NOTE
Den här konfigurationen utnyttjar Renderare för fjärrinnehåll, som har ytterligare alternativ för tillägg och anpassning.

AEM kommunikationsflöde

När SSR används arbetsflöde för komponentinteraktion SPA i AEM innehåller en fas i vilken det inledande innehållet i appen genereras av Adobe I/O Runtime.

  1. Webbläsaren begär SSR-innehåll från AEM.
  2. AEM skickar modellen till Adobe I/O Runtime.
  3. Adobe I/O Runtime returnerar det genererade innehållet
  4. AEM visar HTML som returneras av Adobe I/O Runtime via HTML-mallen för backend-sidkomponenten.

serverside-rendering-cms-drivenaemnode

Adobe I/O Runtime-drivet kommunikationsflöde

Avsnittet AEM kommunikationsflöde beskriver standardimplementeringen och den rekommenderade implementeringen av serversidorendering med avseende på SPA i AEM, där AEM utför startsvällning och -visning av innehåll.

Alternativt kan SSR implementeras så att Adobe I/O Runtime ansvarar för startkomponenten, vilket effektivt kan vända kommunikationsflödet.

Båda modellerna är giltiga och stöds av AEM. Man bör dock beakta fördelarna och nackdelarna med var och en av modellerna innan man implementerar en viss modell.

BootstrapFördelarNackdelar
via AEMAEM hanterar inmatning av bibliotek där det behövs
Resurserna behöver bara underhållas på AEM		SPA utvecklare kanske inte känner till
via Adobe I/O RuntimeMer bekant för SPA utvecklareClientlib-resurser som krävs av programmet, t.ex. CSS och JavaScript, måste göras tillgängliga av AEM utvecklare via allowProxy property
Resurserna måste synkroniseras mellan AEM och Adobe I/O Runtime
Om du vill aktivera redigering av SPA kan det behövas en proxyserver för Adobe I/O Runtime

Planering för SSR

I allmänhet behöver bara en del av ett program återges på serversidan. Det vanliga exemplet är det innehåll som ska visas ovanför vikningen vid den första inläsningen av sidan måste återges på serversidan. Detta sparar tid genom att leverera till klienten, som redan har återgett innehåll. När användaren interagerar med SPA återges det extra innehållet av klienten.

När du funderar på att implementera serversidorendering för SPA måste du granska vilka delar av appen som kräver SSR.

Utveckla en SPA med SSR

SPA kan återges av klienten (i webbläsaren) eller serversidan. Webbläsaregenskaper som fönsterstorlek och plats finns inte på den återgivna serversidan. SPA bör därför vara isomorfa, utan att man vet var de kommer att återges.

Om du vill använda SSR måste du distribuera koden i AEM och på Adobe I/O Runtime, som ansvarar för återgivningen på serversidan. Den mesta koden blir densamma, men serverspecifika åtgärder skiljer sig åt.

SSR för SPA i AEM

SSR för SPA i AEM kräver Adobe I/O Runtime, vilket krävs för återgivning av programinnehållsserversidan. I programmets HTML anropas en resurs på Adobe I/O Runtime för att återge innehållet.

Precis som AEM stöder ramverken Angular och React SPA direkt, stöds även serversidorendering för Angular- och React-appar. Mer information finns i NPM-dokumentationen för båda ramverken.

Ett enkelt exempel finns i App för återförsäljningsjournal. Det återger hela programserversidan. Även om detta inte är ett verkligt exempel visar det vad som behövs för att implementera SSR.

CAUTION
The App för återförsäljningsjournal är endast till för demonstrationsbruk och använder därför Node.js som ett enkelt exempel i stället för den rekommenderade Adobe I/O Runtime. Det här exemplet ska inte användas för något projektarbete.
NOTE
Alla AEM ska utnyttja AEM Project Archetype, som stöder SPA projekt med React eller Angular och använder SPA SDK.

Använda Node.js

Adobe I/O Runtime rekommenderas för implementering av SSR för SPA i AEM.

För premesis AEM-instanser är det också möjligt att implementera SSR med en anpassad Node.js-instans på samma sätt som beskrivs ovan. Även om detta stöds av Adobe rekommenderas det inte.

Node.js stöds inte för instanser med värdbaserade AEM i Adobe.

NOTE
Om SSR måste implementeras via Node.js rekommenderar Adobe en separat Node.js-instans för varje AEM (författare, publicering, scen osv.).

Renderare för fjärrinnehåll

The Konfiguration av fjärrinnehållsrenderare som krävs för att använda SSR tillsammans med SPA i AEM går in i en mer generaliserad renderingstjänst som kan byggas ut och anpassas efter dina behov.

RemoteContentRenderingService

RemoteContentRenderingService är en OSGi-tjänst som hämtar innehåll som återges på en fjärrserver, till exempel från Adobe I/O. Innehållet som skickas till fjärrservern baseras på den begärandeparameter som skickas.

RemoteContentRenderingService kan injiceras genom beroendeinvertering till antingen en anpassad Sling-modell eller servlet när ytterligare innehållsmanipulering krävs.

Den här tjänsten används internt av RemoteContentRendererRequestHandlerServlet.

RemoteContentRendererRequestHandlerServlet

The RemoteContentRendererRequestHandlerServlet kan användas för att ställa in konfigurationen för begäran programmatiskt. DefaultRemoteContentRendererRequestHandlerImpl, den medföljande standardimplementeringen av begäranhanteraren, gör att du kan skapa flera OSGi-konfigurationer för att mappa en plats i innehållsstrukturen till en fjärrslutpunkt.

Implementera RemoteContentRendererRequestHandler gränssnitt. Var noga med att ange Constants.SERVICE_RANKING egenskapen component till ett heltal som är högre än 100, vilket är rankningen för DefaultRemoteContentRendererRequestHandlerImpl.

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

Konfigurera OSGi-konfigurationen för standardhanteraren

Konfigurationen av standardhanteraren måste konfigureras enligt beskrivningen i avsnittet Konfiguration av fjärrinnehållsrenderare.

Användning av fjärråtergivning av innehåll

Så här hämtar du en servlet och returnerar innehåll som kan injiceras på sidan:

  1. Kontrollera att fjärrservern är tillgänglig.
  2. Lägg till ett av följande kodfragment i HTML-mallen för en AEM.
  3. Du kan också skapa eller ändra OSGi-konfigurationerna.
  4. Bläddra i webbplatsens innehåll

Vanligtvis är HTML-mallen för en sidkomponent huvudmottagaren för en sådan funktion.

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

Krav

Servlets använder Sling Model Exporter för att serialisera komponentdata. Som standard är båda com.adobe.cq.export.json.ContainerExporter och com.adobe.cq.export.json.ComponentExporter stöds som Sling Model-kort. Om det behövs kan du lägga till klasser som begäran ska anpassas till med RemoteContentRendererServlet och implementera RemoteContentRendererRequestHandler#getSlingModelAdapterClasses. Ytterligare klasser måste utöka ComponentExporter.

Föregående sida
Nästa sida

Experience Manager