Server Side Rendering (SSR) Technical Implementation Architecture

The SSR (Server Side Rendering) architecture provides personalized experiences while maintaining flexibility and scalability.

Introduction

This document outlines the Server Side Rendering (SSR) architecture, focusing on how it handles personalized content delivery using both Personalize Edge API and CMS Delivery API.

The architecture combines the power of edge processing with robust content delivery capabilities to provide personalized user experiences. It's ideal for businesses looking to enhance engagement through personalization while maintaining scalability and performance.

Note: This document provides a high-level overview. For details on how to use Personalize and other best practices, refer to Contentstack's official documentation and consult with our support team.

Key Components

The architecture involves three main components: Browser, Customer Origin, Personalize Edge API, and CMS Delivery API. Below is a detailed breakdown of each component and its role in the system:

• Browser: The browser is where user interaction begins. It collects events and attributes based on user actions or predefined triggers. This data is critical for enabling personalization.
• Your Origin: This component represents your origin server, where the initial user request is processed. It is recommended that custom caching mechanisms are used in front of the origin to improve performance. This ensures faster data retrieval and reduces latency, especially when delivering personalized content to users.

  The User’s Variants (or the Entry Variants in the CMS which has the personalized content variations tailored for the user) are also routed back through the Customer Origin.

• Personalize Edge API: The Personalize Edge API plays a critical role in processing the collected events and attributes from the browser.

  It evaluates these events to identify the appropriate Entry Variants (personalized experiences) that will be served. It ensures that users receive highly tailored content based on their interaction history or defined segments.

• CMS Delivery API: The CMS Delivery API is responsible for delivering the personalized content that has been selected via the Personalize Edge API.

  This API ensures that the final content displayed to the user is relevant, dynamically generated, and optimized for performance.

Benefits of this Architecture

This architecture ensures:

• Low Latency: Cach responses by setting up a CDN between your origin and the browser and using the Personalize Edge API, can ensure minimal delays in delivering personalized content.
• Scalability: The architecture can handle high traffic volumes, if a CDN is used for caching, and deliver personalized content to large user bases without performance degradation.
• Flexibility: The use of the Personalize Edge API allows for dynamic personalization, meaning content can adapt in real time based on user interactions.
• Optimized Delivery: By utilizing the CMS Delivery API, content can be pulled from a centralized content repository, ensuring consistency and ease of management across multiple personalization variants.

Flow of the Diagram

The diagram outlines the flow of data and interactions between the components:

• Browser: The user interacts with the browser, generating events and attributes such as location, device type, or behavioral preferences. These events are captured and sent to the system.
• Your Origin: The browser forwards these events/attributes to your Origin, which is the customer's server-side infrastructure. Here, caching mechanisms are implemented to optimize performance.

  Your origin routes the collected data to the next component based on the predefined logic, sending the data to the Personalize Edge API for further processing.

• Personalize Edge API: The Personalize Edge API receives the data from your Origin and processes it to determine the most relevant User's Variants (i.e., personalized experiences tailored to the user). These variants are derived based on the events and attributes from the browser.

  The selected variant is then returned to your Origin to be used in delivering personalized content.

• CMS Delivery API: Alongside the Personalize Edge API, the CMS Delivery API is responsible for delivering the actual personalized content based on the user’s variants.

  The CMS Delivery API ensures the right content, such as customized articles, images, or other media, is fetched and sent back to your Origin.

• Final Delivery: Your Origin server takes the personalized content and User’s Variants from the two APIs (Personalize Edge API and CMS Delivery API) and delivers them to the user's browser.

  The user now sees tailored content based on their attributes and interactions, completing the data flow cycle.

Data Flow and Personalization Process

This section describes how data flows through the system to deliver personalized content:

• User Interaction: The user's browser sends events/attributes to the system based on their actions, preferences, or session data.
• Edge Processing: The Personalize Edge API receives this data and determines the user’s variant based on preconfigured rules or personalization criteria.
• Content Selection: Once the variant is selected, the CMS Delivery API retrieves the corresponding personalized content. This content could be pre-cached or dynamically generated based on the user profile.
• Response: The system then returns the personalized content to your Origin server, which sends it back to the browser for display.

Technical Considerations

While considering this implementation, the following points can help:

• Caching: It's crucial to configure caching, through CDN for better performance, particularly for high-traffic applications.
• Security: Ensure that user data and personalized content delivery are protected through secure APIs, especially when handling sensitive information.