Show Menu
THEMEN×

SPA- und serverseitiges Rendering

Der SPA-Editor ist die empfohlene Lösung für Projekte, bei denen clientseitiges Rendering (z.B. React oder Angular) durch das SPA-Framework erforderlich ist.
AEM 6.5.1.0 oder höher ist erforderlich, um die Funktionen zum Rendern auf der Seite des SPA-Servers zu verwenden, wie in diesem Dokument beschrieben.

Übersicht

Einzelseitenanwendungen (SPAs) können dem Anwender ein umfangreiches, dynamisches Erlebnis Angebot werden, das auf vertraute Weise reagiert und sich verhält, oft genau wie eine native Anwendung. Dies wird erreicht, indem der Client den Inhalt vorab lädt und dann die Benutzerinteraktion intensiv aufhebt und so die erforderliche Kommunikation zwischen Client und Server minimiert, wodurch die App reaktiver wird.
Dies kann jedoch zu längeren anfänglichen Ladezeiten führen, insbesondere wenn die SPA groß und inhaltlich reich ist. Um die Ladezeit zu optimieren, können einige Inhalte serverseitig wiedergegeben werden. Die Verwendung des serverseitigen Renderings (SSR) kann das anfängliche Laden der Seite beschleunigen und dann das Rendering an den Client weiterleiten.

Verwendung von SSR

SSR ist nicht für alle Projekte erforderlich. Obwohl AEM JS SSR für SPA vollständig unterstützt, empfiehlt Adobe nicht, es systematisch für jedes Projekt zu implementieren.
Bei der Entscheidung, SSR zu implementieren, müssen Sie zunächst abschätzen, welche zusätzliche Komplexität, Aufwand und Kostenaufstockung SSR realistisch für das Projekt, einschließlich der langfristigen Wartung, darstellen. Eine SSR-Architektur sollte nur gewählt werden, wenn der Mehrwert die geschätzten Kosten deutlich übersteigt.
SSR bietet in der Regel einen Wert, wenn eine der folgenden Fragen mit einem klaren Ja beantwortet wird:
  • SEO: Ist SSR noch immer erforderlich, damit Ihre Site von den Suchmaschinen, die Traffic bringen, korrekt indiziert wird? Denken Sie daran, dass die wichtigsten Suchmaschinen-Crawler jetzt JS bewerten.
  • Seitengeschwindigkeit: Bietet SSR eine messbare Geschwindigkeitsverbesserung in Echtzeit-Umgebung und steigert die Benutzerfreundlichkeit insgesamt?
Nur wenn mindestens eine dieser beiden Fragen mit einem klaren Ja für Ihr Projekt beantwortet wird, empfiehlt Adobe die Implementierung von SSR. In den folgenden Abschnitten wird beschrieben, wie Sie dies mit der Adobe I/O-Laufzeit tun.

Adobe I/O-Laufzeit

Wenn Sie sicher sind, dass Ihr Projekt die Implementierung der SSR erfordert, empfiehlt Adobe die Verwendung der Adobe I/O-Laufzeit.
Weitere Informationen zur Adobe I/O-Laufzeit finden Sie unter
In den folgenden Abschnitten wird erläutert, wie Adobe I/O Runtime zum Implementieren von SSR für Ihre SPA in zwei verschiedenen Modellen verwendet werden kann:
Adobe empfiehlt für jede AEM-Umgebung (Autor, Veröffentlichen, Stage usw.) eine separate Adobe I/O-Laufzeitinstanz.

Remote Renderer-Konfiguration

AEM muss wissen, wo der remote gerenderte Inhalt abgerufen werden kann. Unabhängig davon, welches Modell Sie für SSR implementieren, müssen Sie AEM angeben, wie auf diesen Remote-Rendering-Dienst zugegriffen werden soll.
Dies erfolgt über den RemoteContentRenderer - Configuration Factory OSGi-Dienst . Suchen Sie in der Web-Konsolenkonfiguration nach der Zeichenfolge "RemoteContentRenderer"unter http://<host>:<port>/system/console/configMgr .
Die folgenden Felder stehen für die Konfiguration zur Verfügung:
  • Inhaltspfadmuster - Regulärer Ausdruck, um bei Bedarf einen Inhaltsbereich zuzuordnen
  • Remote-Endpunkt-URL - URL des Endpunkts, der für die Erstellung des Inhalts verantwortlich ist
    • Verwenden Sie das gesicherte HTTPS-Protokoll, wenn nicht im lokalen Netzwerk.
  • Zusätzliche Anforderungsheader - Zusätzliche Header, die der an den Remote-Endpunkt gesendeten Anforderung hinzugefügt werden
    • Muster: key=value
  • Anfrage-Timeout - Zeitlimit für Remote-Host-Anfrage in Millisekunden
Unabhängig davon, ob Sie sich für die Implementierung des AEM-basierten Kommunikationsflusses oder des Adobe-I/O-Laufzeitflusses entscheiden, müssen Sie eine Remote-Konfiguration des Inhalts-Renderers definieren.
Diese Konfiguration muss auch definiert werden, wenn Sie einen benutzerdefinierten Node.js-Server verwenden.
Diese Konfiguration nutzt den Remote Content Renderer, der über zusätzliche Erweiterungs- und Anpassungsoptionen verfügt.

AEM-gesteuerter Kommunikationsfluss

Bei Verwendung von SSR umfasst der Komponenteninteraktionsarbeitsablauf von SPAs in AEM eine Phase, in der der ursprüngliche Inhalt der App in der Adobe I/O-Laufzeit generiert wird.
  1. Der Browser fordert den SSR-Inhalt von AEM an.
  2. AEM sendet das Modell zur Adobe I/O-Laufzeit.
  3. Adobe I/O Runtime gibt den generierten Inhalt zurück.
  4. AEM stellt das von Adobe I/O Runtime zurückgegebene HTML über die HTML-Vorlage der Backend-Seitenkomponente bereit.

Adobe I/O-Laufzeitgesteuerter Kommunikationsfluss

Im vorherigen Abschnitt wird die standardmäßige und empfohlene Implementierung des serverseitigen Renderings in Bezug auf SPAs in AEM beschrieben, bei denen AEM das Bootstrapping und Bereitstellen von Inhalten ausführt.
Alternativ kann SSR implementiert werden, sodass Adobe I/O Runtime für das Bootstrapping verantwortlich ist und den Kommunikationsfluss effektiv umkehrt.
Beide Modelle sind gültig und werden von AEM unterstützt. Vor der Einführung eines bestimmten Modells sollten jedoch die Vor- und Nachteile jedes einzelnen Modells berücksichtigt werden.
Bootstrapping Vorteile Nachteile
über AEM
  • AEM verwaltet die Injektion von Bibliotheken bei Bedarf
  • Ressourcen müssen nur auf AEM beibehalten werden
  • Möglicherweise nicht mit SPA-Entwicklern vertraut
über Adobe I/O Runtime
  • Eingehendere Kenntnisse der SPA-Entwickler
  • Für die Anwendung erforderliche Clientlib-Ressourcen wie CSS und JavaScript müssen vom AEM-Entwickler über die allowProxy Eigenschaft verfügbar gemacht werden
  • Ressourcen müssen zwischen AEM und Adobe I/O Runtime synchronisiert werden
  • Um das Authoring der SPA zu aktivieren, ist unter Umständen ein Proxyserver für die Adobe I/O Runtime erforderlich.

Planung für SSR

Im Allgemeinen muss nur ein Teil einer Anwendung serverseitig gerendert werden. Das allgemeine Beispiel ist der Inhalt, der über der Kante beim ersten Laden der Seite angezeigt wird, wird serverseitig gerendert. Dies spart Zeit, indem bereits gerenderte Inhalte an den Client gesendet werden. Wenn der Benutzer mit der SPA interagiert, wird der zusätzliche Inhalt vom Client gerendert.
Wenn Sie erwägen, das serverseitige Rendering für Ihre SPA zu implementieren, müssen Sie überprüfen, welche Teile der App erforderlich sind.

Entwickeln einer SPA mit SSR

SPA-Komponenten können vom Client (im Browser) oder vom Server gerendert werden. Beim Rendern auf Serverseite sind keine Browsereigenschaften wie Fenstergröße und -position vorhanden. Daher sollten SPA-Komponenten isomorphisch sein, sodass keine Annahme darüber besteht, wo sie gerendert werden.
Um SSR zu nutzen, müssen Sie Ihren Code in AEM sowie in Adobe I/O Runtime bereitstellen, die für das serverseitige Rendering zuständig ist. Der Großteil des Codes ist gleich, jedoch unterscheiden sich serverspezifische Aufgaben.

SSR für SPAs in AEM

SSR für SPAs in AEM erfordern Adobe I/O Runtime, die für die Wiedergabe der App Content Server-Seite aufgerufen wird. Innerhalb der HTL der App wird eine Ressource auf der Adobe I/O-Laufzeit aufgerufen, um den Inhalt wiederzugeben.
Genau wie AEM die standardmäßigen SPA-Frameworks Angular und React unterstützt, wird auch das serverseitige Rendering für Angular- und React-Apps unterstützt. Weitere Informationen finden Sie in der NPM-Dokumentation für beide Frameworks.
Ein einfaches Beispiel finden Sie in der Web.Retail-Protokoll-App . Es rendert die gesamte Anwendungsserverseite. Obwohl dies kein echtes Beispiel ist, zeigt es doch, was zur Umsetzung der Reform des Sicherheitssektors erforderlich ist.
Die Web.Retail-Protokoll-App dient nur zu Demonstrationszwecken und verwendet daher Node.js als einfaches Beispiel anstelle der empfohlenen Adobe I/O-Laufzeit. Dieses Beispiel sollte für keine Projektarbeit verwendet werden.
Jedes AEM-Projekt sollte den AEM-Projektarchiv nutzen, der SPA-Projekte mit React oder Angular unterstützt und das SPA-SDK nutzt.

Verwenden von Node.js

Adobe I/O Runtime ist die empfohlene Lösung für die Implementierung von SSR für SPAs in AEM.
Bei AEM-Instanzen im Vorfeld ist es auch möglich, SSR mit einer benutzerdefinierten Node.js-Instanz zu implementieren, wie oben beschrieben. Dies wird zwar von Adobe unterstützt, wird jedoch nicht empfohlen.
Node.js wird für von Adobe gehostete AEM-Instanzen nicht unterstützt.
Wenn SSR über Node.js implementiert werden muss, empfiehlt Adobe für jede AEM-Umgebung (Autor, Veröffentlichung, Stage usw.) eine separate Node.js-Instanz.

Remote Content Renderer

Die Remote Content Renderer-Konfiguration , die zur Verwendung von SSR mit Ihrer SPA in AEM erforderlich ist, fügt sich in einen allgemeineren Renderdienst ein, der erweitert und an Ihre Anforderungen angepasst werden kann.

RemoteContentRenderingService

RemoteContentRenderingService ist ein OSGi-Dienst zum Abrufen von Inhalten, die auf einem Remote-Server wiedergegeben werden, z. B. von Adobe I/O. Der an den Remote-Server gesendete Inhalt basiert auf dem weitergeleiteten Anforderungsparameter.
RemoteContentRenderingService kann durch Abhängigkeitsinversion in ein benutzerdefiniertes Sling-Modell oder Servlet eingefügt werden, wenn zusätzliche Inhaltsbearbeitung erforderlich ist.
Dieser Dienst wird intern vom RemoteContentRendererRequestHandlerServlet verwendet.

RemoteContentRendererRequestHandlerServlet

Mit der RemoteContentRendererRequestHandlerServlet können Sie die Anforderungskonfiguration programmgesteuert einstellen. DefaultRemoteContentRendererRequestHandlerImpl , der bereitgestellten standardmäßigen Implementierung des Anforderungs-Handlers, ermöglicht Ihnen, mehrere OSGi-Konfigurationen zu erstellen, um einen Speicherort in der Inhaltsstruktur einem Remote-Endpunkt zuzuordnen.
Um einen benutzerdefinierten Anforderungs-Handler hinzuzufügen, implementieren Sie die RemoteContentRendererRequestHandler Schnittstelle. Stellen Sie sicher, dass die Constants.SERVICE_RANKING component-Eigenschaft auf eine Ganzzahl größer als 100 gesetzt wird, was der Rangfolge der Komponente entspricht DefaultRemoteContentRendererRequestHandlerImpl .
@Component(immediate = true,
        service = RemoteContentRendererRequestHandler.class,
        property={
            Constants.SERVICE_RANKING +":Integer=1000"
        })
public class CustomRemoteContentRendererRequestHandlerImpl implements RemoteContentRendererRequestHandler {}

OSGi-Konfiguration des Standardhandlers konfigurieren

Die Konfiguration des Standard-Handlers muss wie im Abschnitt Remote Content Renderer-Konfiguration beschrieben konfiguriert werden.

Remote Content Renderer-Nutzung

So rufen Sie ein Servlet ab und geben Inhalte zurück, die in die Seite eingefügt werden können:
  1. Stellen Sie sicher, dass auf den Remote-Server zugegriffen werden kann.
  2. Hinzufügen eines der folgenden Snippets zur HTML-Vorlage einer AEM-Komponente.
  3. Optional können Sie die OSGi-Konfigurationen erstellen oder ändern.
  4. Durchsuchen des Inhalts Ihrer Site
In der Regel ist die HTL-Vorlage einer Seitenkomponente der wichtigste Empfänger einer solchen Funktion.
<sly data-sly-resource="${resource @ resourceType='cq/remote/content/renderer/request/handler'}" />

Voraussetzungen

Die Servlets verwenden den Sling Model Exporter, um die Komponentendaten zu serialisieren. Standardmäßig werden sowohl das com.adobe.cq.export.json.ContainerExporter als auch com.adobe.cq.export.json.ComponentExporter als Sling Model-Adapter unterstützt. Bei Bedarf können Sie Klassen hinzufügen, die an die Verwendung der Variablen RemoteContentRendererServlet und die Implementierung der Anforderung angepasst werden sollen RemoteContentRendererRequestHandler#getSlingModelAdapterClasses . Die zusätzlichen Klassen müssen den ComponentExporter Wert erweitern.