Sitecore released Experience Edge capabilities a while back for their Content Hub (SaaS) product and their traditional XM (PaaS) CMS offering. What exactly is Experience Edge? If you think about the future vision of Sitecore's Composable DXP and the necessary architecture to support that, you can understand the role Experience Edge plays. Let's dig in and see how this fits, even in a traditional architecture.

Sitecore Experience Edge: Decoupling the API at the Edge

For those with prior experience with Sitecore, the simplest definition I can give of Experience Edge is a modern replacement/substitute for Content Delivery (CD) servers. It's much more than that, but that's an easy mental model to wrap your head around its role. 

In a traditional XP/XM/XC platform-based scaled architecture, you will have at minimum a Content Management (CM) server hosting the back-end CMS and preview features, and one or more Content Delivery (CD) servers, rendering your site(s) to end users. The CM facilitates publishing (that is, moving content from the master database to the web database), and the CD reads the web database content and renders pages (traditionally via server-side .NET).

Experience Edge for XM removes the need to host a set of CD servers on PaaS infrastructure and becomes a proxy layer between the CMS and the front-end customer experience. This does come with the requirement that you are using the headless APIs provided by Experience Edge, as opposed to building a traditional MVC solution on XM that uses C# APIs. However, thats the future vision of the composable DXP with XM Cloud (the future CMS) being fully headless and decoupled. The primary point here is that you are able to start to take advantage of a decoupled architecture using headless services for your front-end experience, even on a traditional XM PaaS deployment. While doing so you can shed the burden of hosting and scaling CD servers and allow Experience Edge to replace them as an API proxy.

That's it? No…

There's so much more. Experience Edge is provided as SaaS from Sitecore. Think of it as a Sitecore-provided CDN for your headless APIs that sits on top of your PaaS-hosted XM instance. You manage your XM instance in a PaaS hosting environment, and it publishes content to Sitecore's hosted Experience Edge which serves your GraphQL APIs for your front-end experience. From there you build and deploy whatever headless front-end experience you want, from a JavaScript-based site (React, Next.js, Angular, etc.) or a .NET Core site if you are C# .NET developer.

Good use cases for Experience Edge

There are a number of uses case of when it makes sense to leverage Experience Edge vs. hosting a set of CD servers in a PaaS environment:

• A content marketing website with largely static content - that is, non user-generated content (like blog comments). Even dynamic content from CMS publishing or time-based updates to content can be solved with static site generation (SSG) and incremental site regeneration (ISR).
• Native mobile apps that need to consume and surface CMS-managed content. These implementations are by definition headless, in that they use web APIs to deliver content from Sitecore to the app via its native code. Experience Edge will provide highly performant API endpoints for the native app to consume content, regardless of the state of the CMS (XM) behind the scenes.
• Bespoke single page apps (SPAs). This is related to content marketing sites, but in the case of a JavaScript-driven SPA, this is a great use case for using a performant headless API. We implemented a 3D virtual experience SPA that relied on a browser-based panoramic tool which was fed with CMS-managed content. This required the use of headless APIs to drive the experience.
• Chatbots and virtual assistants - pretty much anything that needs to consume raw content as-is. The UX of a chatbot is provided by the chatbot technology, but it requires input from customers (questions) and output content from.... somewhere. Why not store that content in a CMS? This is a perfect use case of a API to deliver the content.
• Authenticated portals - this one might sound peculiar, but its actually quite a good use case. If you need to build a portal with a logged in state, chances are a lot of the data to hydrate in the portal comes from another system of truth, e.g. an ERP or some other back-office system. It's not likely you are driving all of the content/data from a CMS, but a CMS can help augment content in the portal, such as page definitions/URLs, basic header titles, imagery, SEO content, etc. Chances are you can architect the custom web experience implementation of the portal with the back-office system in mind, e.g. using a specific back-office technology as the first reponder to your web portal, and then integrate it with the Experience Edge GraphQL APIs where needed to fetch CMS-driven content.