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…
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.
- 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.