SPA- och serveråtergivning spa-and-server-side-rendering

Single page-applikationer (SPA) kan ge användaren en rik, dynamisk upplevelse som reagerar och beter sig på välbekanta sätt, ofta precis som ett systemspecifikt program. Den här funktionaliteten uppnås genom att klienten förlitar sig på att läsa in innehållet i förväg och sedan göra en grov förbättring av användarinteraktionen. Den här processen minimerar mängden kommunikation som krävs mellan klienten och servern, vilket gör programmet mer reaktivt.

Den här processen 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. Med SSR-återgivning (server-side rendering) går sidans initiala belastning snabbare och skickar sedan vidare återgivning till klienten.

Använd SSR when-to-use-ssr

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 din webbplats 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 förbättrar 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, som ingår i App Builder.

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

Om du är säker på att ditt projekt kräver implementering av SSR rekommenderar Adobe att du använder Adobe I/O Runtime.

Mer information om Adobe I/O Runtime finns i:

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ö (stage, prod, testing osv.). Detta möjliggör typiska mönster för systemutvecklingscykler (SDLC) med olika versioner av ett program som distribueras till olika miljöer. Mer information finns i CI/CD for App Builder Applications.
En separat arbetsyta behövs inte per instans (författare, publicering) såvida det inte finns skillnader i körtidsimplementeringen per instanstyp.
NOTE
Cloud Manager stöder inte distribution till Adobe I/O Runtime. Därför måste din egen infrastruktur vara konfigurerad för att distribuera SSR-kod till Adobe I/O Runtime.

Fjärrrenderarkonfiguration remote-content-renderer-configuration

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 hur du ska AEM åtkomst till den här fjärråtergivningstjänsten.

Den här tjänsten utförs med hjälp av RemoteContentRenderer - Configuration Factory OSGi-tjänsten. Sök efter strängen RemoteContentRenderer i webbkonsolens konsol på http://<host>:<port>/system/console/configMgr.

Återgivningskonfiguration

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

  • Mönster för innehållssökväg - Reguljärt uttryck som matchar 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ärandehuvuden - Ytterligare huvuden 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 det AEM kommunikationsflödet eller det Adobe I/O Runtime-drivna flödet måste du definiera en fjärrkonfiguration för innehållsåtergivning.
NOTE
Den här konfigurationen använder Renderer för fjärrinnehåll, som har ytterligare tillgängliga tillägg och anpassningsalternativ.

AEM kommunikationsflöde aem-driven-communication-flow

När du använder SSR innehåller komponentens interaktionsarbetsflöde för SPA i AEM en fas i vilken det inledande innehållet i appen genereras på 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.

SSE CMS-driven AEM Adobe I/O

Adobe I/O Runtime-drivet kommunikationsflöde adobe-i-o-runtime-driven-communication-flow

I det föregående avsnittet beskrivs standardimplementeringen och den rekommenderade implementeringen av serversidesåtergivning för 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.

Bootstrap
Fördelar
Nackdelar
via AEM
  • AEM hanterar inmatning av bibliotek där det behövs
  • Underhåll endast resurser på AEM
  • SPA utvecklaren
    kanske inte känner till
via Adobe I/O Runtime
  • Mer bekant för SPA utvecklare
  • Klientlib-resurser som krävs av programmet, t.ex. CSS och JavaScript, måste göras tillgängliga av den AEM utvecklaren via egenskapen allowProxy
  • 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 planning-for-ssr

I allmänhet får endast en del av ett program återges på serversidan. Det vanliga exemplet är det innehåll som visas ovanför vikningen vid den första inläsningen av sidan återges på serversidan. Den här processen 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 serversidesåtergivning för SPA kan du kontrollera vilka delar av programmet som behövs.

Utveckla en SPA med SSR developing-an-spa-using-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 å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 är densamma, men serverspecifika åtgärder skiljer sig åt.

SSR för SPA i AEM ssr-for-spas-in-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 serversidesrendering för Angular- och React-appar. Mer information finns i NPM-dokumentationen för båda ramverken.

Renderare för fjärrinnehåll remote-content-renderer

Den Remote Content Renderer Configuration som krävs för att använda SSR med SPA i AEM finns i en mer generaliserad renderingstjänst som kan utökas och anpassas efter dina behov.

RemoteContentRenderingService remotecontentrenderingservice

RemoteContentRenderingService 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 en servlet när ytterligare innehållsmanipulering krävs.

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

RemoteContentRendererRequestHandlerServlet remotecontentrendererrequesthandlerservlet

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

Implementera gränssnittet RemoteContentRendererRequestHandler om du vill lägga till en anpassad begärandehanterare. Se till att du ställer in Constants.SERVICE_RANKING-komponentegenskapen på 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 configure-default-handler

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

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

Ta en servlet och returnera innehåll som har injicerats 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 requirements

Servlets använder Sling Model Exporter för att serialisera komponentdata. Som standard stöds både com.adobe.cq.export.json.ContainerExporter och com.adobe.cq.export.json.ComponentExporter 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. De ytterligare klasserna måste utöka ComponentExporter.

recommendation-more-help
fbcff2a9-b6fe-4574-b04a-21e75df764ab