Name: Introducing Server Side Rendering (SSR) in SAP Commerce Cloud Composable Storefront
Uploaded: 2023-11-1
Duration: 563 s
Description: In this video, you will learn what SSR is, why you need to enable it, and how it works within Composable Storefront.

Share feedback

<p>Planned maintenance of Practice Systems</p>

Planned maintenance of Practice Systems

Why create an SAP account?

Enhance your learning experience

SAP Learning

Subscribe now

Learn more

Live Sessions

Hands-on Practice

Certification

My Learning

Ready to start learning?

<div><div><div><div>In this video, you will learn what SSR is, why you need to enable it, and how it works within Composable Storefront.<br></div></div></div></div>

Introducing Server Side Rendering (SSR) in SAP Commerce Cloud Composable Storefront

Hello everyone. In this video, I’m going to talk about  what SSR is, why we would want to enable SSR, and how SSR works in composable Storefront. Let’s start with What is SSR? In Client-Side Rendering, (i.e., CSR),  Angular handles rendering of the application pages fully within the browser.  The browser calls Commerce Cloud REST APIs  to fetch page structure,  then page data to fill the structure.   In Server-Side Rendering, (i.e., SSR),  rendering of the application is handled  on the server, which generates HTML content to send to the browser.  Once the HTML content is rendered in a browser Angular bootstraps an application  and reuses the information available  in the server-generated HTML.   Angular Universal is a technology that allows Angular to render applications on the server.   This is the homepage response  in Client-Side Rendering for the storefront.    The browser makes REST API requests,  and pages will be completely rendered in the Browser.  Whereas in Server-Side Rendering,  pre-rendered HTML content is returned from the server.  Next, Why SSR?  SSR is required for improving Search-Engine Optimization (SEO).  Search-Engine Optimization  is often critical for B2C commerce.   Google, Bing, Facebook, and other social media sites rely on web crawlers to index your application content  and make that content searchable on the web.   These web crawlers might be enabled  to navigate and index your highly interactive Angular application as a human could do.   Angular Universal can generate  a static version of your application  that is easily searchable, linkable,  and navigable without JavaScript.  Universal also makes a site preview available  because each URL returns a fully rendered page.  SSR also helps improve performance.  Displaying the first page quickly  can be critical for user engagement.   Pages that load faster result in a better user experience.   With Server-Side Rendering, you can generate landing pages  for the application that look like  the complete application and speed-up initial-page load time.    SSR also improves performance on mobile  and low-powered devices.    Some devices don't support JavaScript,  or execute JavaScript so slowly  that the user experience is unacceptable.    These cases might require a Server-Side rendered,  no-JavaScript version of the application.   Let’s see SSR within a composable storefront.   I’ll show you how to add SSR support  to an existing composable storefront.   Run this command to add SSR support.    This will add SSR support;  you can see that SSR-related dependencies  are installed and required files are created and updated.  Let’s see what files are created.    Required dependencies: angular platform-server, express-engine, Spartacus setup,  and node express are added.   These SSR scripts are also added in package.json Also created, was the main.server typescript file  which is the bootstrapper for the server app as well as the server-side application module files.  A TypeScript server application configuration  file is created.    The main thing to notice is the express web server server.ts file.   A Node.js Express web server  compiles HTML pages via Universal,  based on client requests.   The ngExpressEngine function is a wrapper around the Angular platform server package’s renderModule  and renderApplication functions,  which turn a client's requests into server-rendered HTML pages.   A Node.js Express Web Server  passes client requests for application  pages to the NgUniversal ngExpressEngine.   Under the hood, the engine renders the app,  while also providing caching and other helpful functionality.   We can now build and run our application.   Enter command npm run build:ssr  This will build our SSR application.   Now start composable storefront in SSR mode,  and enter command npm run serve:ssr  If you try to access your application  and see this error in the logs  due to “SSR certification”  while using a local installation of SAP Commerce Cloud,  then you need to use SSR  with self-signed or untrusted SSR Certificates.   Run this command.    Add the following to package.json .   Then, run this command.  This should not be used in production.  Now your app has started successfully,  and the Node server is returning pre-rendered homepage HTML.   To enable SSR in an SAP Commerce Cloud you need to configure it in the Commerce Cloud manifest.json file as follows:   Set the SSR enable property  to true and include the application name  in the path property.  You can get this manifest.json configuration  from the SAP help documentation  or from the SAP Commerce Cloud sample setup GitHub repository.   In Client-Side Rendering, the web client fetches all static resources  and the bootstrap application.    The web client communicates with the backend  via the REST API.    If an external CDN is being used,  then all static resources such as images, JS, CSS, and cached APIs  are returned from the CDN.   In Server-Side Rendering, the Node.js server  renders the page on the server  and calls REST APIs to get data.    Rendered static HTML content will be returned and the browser will fetch other static resources.  If a CDN is used, then Page responses  can be cached in the CDN  and subsequent requests from the browser and web crawler can be returned from the CDN.  Like web clients, a Web Crawler will also request pages.  Then pre-rendered HTML pages  will be returned either from the server or CDN.    Composable storefront provides an SSR optimization engine and allows you to optimize SSR setup through configuration.   SSR rendering time depends on page complexity and API response time.  SSR Optimization allows you  to configure a timeout for SSR rendering,  concurrency, and cache configuration.   If SSR rendering isn’t quick enough,  then requests fallback to CSR.    The decorator class, NgExpressEngineDecorator from the Spartacus setup/ssr library allows for specifying optimization options like this, and these are the default values.   The NgExpressEngineDecorator class  requires two parameters:  express engine and optimization options.  These default values should be changed  as per your storefront performance level.    These options allow you to control behavior  in case SSR rendering takes  too long for whatever reason.    SSR rendering will fall back  to CSR after the timeout limit,   but the requests still get processed in background. Once rendering is finished,  the page is stored in memory  and served this way on subsequent requests.   The concurrency setting is a number  that limits how many concurrent requests  are handled before falling back to CSR.   The forcedSsrTimeout setting  applies when the rendering strategy  is ALWAYS_SSR and indicates the maximum time to wait for rendering to finish.    The maxRenderTime setting is the maximum amount of time allowed  for rendering to complete.   If rendering exceeds this timeout,  the concurrency slot is released,  which allows the next request to be server-side rendered.   You can refer to SAP help documentation  to see all optimization options.   Not all pages in your application  need to be server-side rendered.  Typically pages that are crawled by web crawlers or bots for search engine optimization  require server-side rendering.  Such pages can also be cached  in a CDN for the anonymous user.  Pages such as cart, checkout,  and my account contain personalized content and are typically not suitable  for server-side rendering.   SSR requires that a few coding guidelines  be followed to get good performance  and to avoid memory leaks and rendering errors.  The most important of these is the use  of global objects such as window, document, and navigator.    These objects do not exist on the server.    Similarly, subscription should be unsubscribed  to avoid memory leaks.    You can refer to the SAP Help documentation for more details on SSR coding guidelines.  Thank you for watching this video.