Although the Single-Page Application (SPA) Editor is available as part of the We.Retail Journal sample content (requires AEM 6.4 service pack 2), its server side rendering features as described in this document are still considered a technical preview, available for testing and feedback but not intended for production roll out.
Single page applications (SPAs) can offer the user a rich, dynamic experience that reacts and behaves in familiar ways, often just like a native application. This is achieved by relying on the client to load the content up front and then do the heavy lifting of handling user interaction and thus minimizing the amount of communication needed between the client and the server, making the app more reactive.
However this can lead to longer initial load times, especially if the SPA is large and rich in its content. In order to optimize load times, some of the content can be rendered server-side. Using server side rendering (SSR) can accelerate the initial load of the page and then pass further rendering on to the client.
When using SSR, the component interaction workflow of SPAs in AEM includes a phase in which the initial content of the app is generated on a Node.js server.
The previous section describes the standard and recommended implementation of server side rendering with regards to SPAs in AEM, where AEM performs the bootstrapping and serving of content.
Alternatively, SSR can be implemented so that the Node.js server is responsible for the bootstrapping, effectively reversing the communication flow.
Both models are valid and supported by AEM. However, one should consider the advantages and disadvantages of each before implementing a particular model.
Generally only part of an application needs to be rendered server side. The common example is the content that will be displayed above the fold on the initial load of the page is rendered server side. This saves time by delivering to the client, already rendered content. As the user interacts with the SPA, the additional content is rendered by the client.
As you consider implementing server side rendering for your SPA, you need to review for what parts of the app it will be necessary.
SPA components could be rendered by the client (in the browser) or server side. When rendered server side, browser properties such as window size and location are not present. Therefore SPA components should be isomorphic, making no assumption about where they will be rendered.
To leverage SSR, you will need to deploy your code in AEM as well as on a Node.js server. Node.js is responsible for the server side rendering. Most of the code will be the same, however server-specific tasks will differ.
SSR for SPAs in AEM require a Node.js server, which is called for the rendering of the app content server side. Within the HTL of the app, a resource on the Node.js server is called to render the content.
Just as AEM supports the Angular and React SPA frameworks out-of-the box, server side rendering is also supported for Angular and React apps. See the NPM documentation for both frameworks for further details.
- React: https://github.com/adobe/aem-sample-we-retail-journal/blob/master/react-app/DEVELOPMENT.md#enabling-the-server-side-rendering-using-the-aem-page-component
- Angular: https://github.com/adobe/aem-sample-we-retail-journal/blob/master/react-app/DEVELOPMENT.md#enabling-the-server-side-rendering-using-the-aem-page-component
For a simplistic example, please refer to the We.Retail Journal app. It renders the entire application server side. Although this is not a real-world example, it does illustrate what is needed to implement SSR.
Adobe recommends a separate Node.js instance for every AEM environment (author, publish, stage, etc.).