PageBuilder, Headless Configurations, Allowed and Not Allowed, CDN Stacking Scenarios
In this doc we’ll explain allowed and not-allowed scenarios customers configure their infrastructure with Arc XP reader experience.
We visualized scenarios explained in this document:
When considering an experience solution, the most important/key determining factor to understand if it’s an allowed or not allowed use case, is how the main web experience is delivered to readers.
The rest of the document will be split in PageBuilder powered web experience (Arc XP hosted and maintained infrastructure) vs Headless experiences (customer owned and maintained infrastructure).
This consideration is also per-site basis. Multi-site customers generally use the same solution for all of their sites, but this is not always the case. If 1 out of 10 sites are considered to have different reader experience delivery (example, an Arc XP customer hosts 9 of their sites with PageBuilder, but wants to host a new experience headlessly, they need to consider that as full headless solution, and not mix two delivery models with each other).
We’ll start with the first question:
Are you hosting your website on PageBuilder?
A) PageBuilder powered web experience
The next question is, how the domain/DNS and CDN is set up.
🟢 1) Custom domain directly points to Arc XP DNS and Arc XP CDN
Most Common PageBuilder, Arc XP Experience Setup:
🟢 2) PageBuilder serves content to Mobile App, OTT apps (while primary web-traffic is still served by PageBuilder)
The second vertical box in the diagram above where the mobile app simply uses ?outputType=mobileapp to retrieve the same content for mobile application format.
The key point here is, as long as the customers primary web traffic is still powered by PageBuilder and customer is not putting an application or CDN proxy in front of these requests, customers can configure their mobile applications (or other experiences like OTT) to directly make requests to Arc XP PageBuilder urls.
🟢 3) Using default arc-cdn.net domains that is already configured with Arc XP DNS and Arc XP CDN
Customers may want to directly use Arc XP provided domains that comes with every Arc site (http://[orgname]-[sitename]-[env].web.arc-cdn.net) configured in Delivery app. Customers can point their web experiences, apps directly to arc-cdn.net domains any time (Example: http://myorg-gazette-prod.web.arc-cdn.net/).
Using arc-cdn.net URLs to PageBuilder, OBF or Resizer:
🔴 4) Custom domain points to customers own DNS (and/or customers CDN), proxied, then points to Arc XP CDN
This is the most common CDN stacking example.
CDN Stacking of PageBuilder, OBF or Resizer:
B) Headless web experience
Arc XP Headless provides more control to customers developer team, on their choice of front-end technologies and strategies. But it increased ownership and maintenance on their part, and customers needs to understand the cache and scale implications when working with Arc XP content platform and headless View API.
There are a few flavors customers may implement Arc XP headless differently based on their architecture of choice.
🟢 5) Client-side Headless Implementation
🟡 6) Server-to-Server Headless Implementation
🟡 6.1) Use Content API instead of View API for their server-to-server integrations
Customers are allowed to make direct content-api calls from their back-end systems. While we don’t advertise, this is an allowed use case, where customer can build their back-end system to serve traffic to their own systems headlessly (no PB).
Key Points about Headless setups:
- A headless customer serving their primary reader experience (web traffic), is not eligible to use non-web traffic use cases of PageBuilder (i.e: OBF, or BFF, more on this in coming sections).
- Notice the diagrams above shows increased customer responsibility and control in their experience stack. This means they have to own the whole stack (mobile/OTT/feeds).
- In both headless implementation flavors, note that Image asset delivery goes through Arc XP CDN, which requires a custom domain (i.e: assets, images, media…) to be set up and configured with Arc XP CDN without stacking. This process requires set up and separately metered/billed Experience Delivery Bandwidth than View API.
🔴 7) NOT Allowed Scenario: Stacking Image Resizer
Customers using Image Resizer (the most common way to serve optimized images publicly), have to use Arc XP CDN and CDN without stacking. Stacking on Image Resizer reduces the resiliency, security, breaks optimizations Image delivery provides, and not allowed.
C) Hybrid or Edge cases that are not allowed
Following scenarios are between the PB and Headless lines and generally not supported/allowed. Here are some common scenarios:
🔴 8) NOT Allowed Scenario: Standalone OBF with Headless Setup
Headless customers often own the whole render stack, except content retrieval. This means they own a request from the readers browser down to their CDN, caching layers, rendering.
A key consideration is how their assets will be served. If customers are using Arc XP Digital Asset Management products, specifically Photo Center, and Image Resizer, they need to comply with CDN stacking policies to send reader traffic directly to Arc XP systems, without a CDN in front. This will require customers to either use arc-cdn.net domains or set up a custom subdomain (i.e: assets.xyz.com, media.xyz.com or images.xyz.com) and configure it to be pointing to Arc XP CDN. Stacking Image Resizer is not allowed.
🔴 9) NOT Allowed Scenario: Using PageBuilder, only for non-web experiences (combined with headless setup)
This scenario often is a transitional period for a PageBuilder customer moving to headless, and want to keep their mobile or OTT applications still using the PageBuilder sourced content delivery. Customers needs to plan for this as part of their headless transition and make sure they do cutover with all of their reader experiences to be switched to their own headless rendering/delivery infrastructure. This hybrid scenario is not supported and generally result CDN stacked set up.
