Getting started on XM Cloud for beginners — 13+1 things that you should know
Sitecore Headless and Sitecore XM Cloud are currently generating a lot of buzz within the Sitecore community. As such, it’s likely you’ll find yourself working on a Sitecore Headless or XM Cloud project in the near future. There are certain considerations and limitations you should bear in mind, particularly if you’re new to Sitecore Headless development.
Transitioning to XM Cloud can pose challenges, as it requires a shift in mindset compared to traditional Sitecore MVC implementation. This transition can be especially challenging if you have no prior experience with headless development.
I tried to collect the most important key points and limitations around XM Cloud that requires special attention when you are switching from Sitecore MVC to XM Cloud. Special thanks to Nick Allen who contributed to the article with some insights.
0. Understand the fundamentals and learn Sitecore Headless
Sitecore Headless development is a completely new development experience. Before you jump into XM Cloud, you should invest time into learning Sitecore Headless. You can read my previous blog post about where you can start it:
Besides that, there are many videos about XM Cloud on YouTube that covers different topics, such as getting started, and migrating legacy projects into XM Cloud.
There is still a chance that you have not used Docker with Sitecore, but if you are starting an XM Cloud and are unfamiliar with Docker, it’s time to get some experience in it too!
Moreover, you can study the best practices for XM Cloud and Experience Edge
1. Local development on XM Cloud?
Yes, it’s possible to develop your solution for XM Cloud. Just grab the official starter kit from GitHub, and start implementing your solution.
Another good thing here is that your frontend developers can connect directly to Experience Edge from their Mac, they don’t need to run XM Cloud containers on a Windows machine. (Of course, a prerequisite is that the content is published to the Experience Edge).
You need to be assigned to at least one Sitecore Cloud organization, otherwise, you can’t run it locally.
2. There is no more Content Delivery server or web database
The most important architectural change in the XM Cloud is that you don’t have Content Delivery servers and the web database anymore (Well, actually web db is still there, but you won’t use it anymore).
Experience Edge is a delivery platform and CDN for your content and media. When you are publishing in XM Cloud, it appears as a new publishing target and you have to publish your content to Experience Edge.
When you are publishing items/pages the following things will be pushed to Experience Edge:
- Individual Content Items and their fields (they will be queryable via GraphQL)
- Snapshot of layout service output. (The snapshots include custom Rendering Contents Resolver generated content for components and further extensions (e.g. route data extensions). It means the layout service is not calculated on the Experience Edge side, it’s just a static snapshot.
- Media Library Assets
Another important thing here is that you don’t want to implement custom WEB APIs anymore on the Sitecore side because there is no CD server and the head is connected to the Experience Edge, not the Sitecore (CM) XM Cloud. If your requirements are not coved by OOTB Rendering Contents resolver you can still write your own custom Rendering Contents resolver (the layout service snapshot is published to Experience Edge) but do not rely on any dynamic input, such as query strings. Or you can still move advanced logic into the head app and perform the logic there after you fetched the necessary data via getstaticprops/GraphQL)
3. Say goodbye to Sitecore Content Search…
… on the public-facing site. The content search is still available in the CM (Content Editor, etc), but you are not allowed to create custom search indexes. On the other hand, there is no web database, so web indexes do not make any sense now. For site searches, you can use any cloud-based search solutions or search-as-a-service platforms, integrated into the head application such as Coveo, Sitecore Search, SearchStax, etc. I don’t want to go into more details, because I will share a blog post soon on possible search/content indexing solutions with XM Cloud.
4. Say Hello to Sitecore CLI
Sitecore CLI is available since Sitecore v10, and now there is an XM Cloud plugin for it that allows you to interact with your XM Cloud instance. You can create projects, environments in XM Cloud or deploy your solutions into the XM Cloud by using CLI. Also, it’s super easy to move items between different items with CLI now, since you can be connected to multiple environments. Some quick cheatsheet:
# cloud login
dotnet sitecore cloud login
# connect to specific environment
dotnet sitecore cloud environment connect -id <env-id> --allow-write
# connect to local env
dotnet sitecore cloud login
dotnet sitecore connect --ref xmcloud --cm https://xmcloudcm.localhost --allow-write true -n local
# Syncing items between different environments
dotnet sitecore ser pull -n "local"
dotnet sitecore ser push -n "xm-cloud-remote-env-name"
# deploying your code to cloud
dotnet sitecore cloud deployment create --environment-id <env-id> --upload
5. Forget Sitecore Security/Users in the head application
Standard fields (like Security, or created/updated fields) are not exposed to Experience Edge. You can read more about the Experience Edge Schema here. If your application requires authentication for users, you can’t use the Sitecore users anymore, since you are decoupled from your CM instance in the head app, and the head app is connected to Experience Edge, not to Sitecore directly.
So authentication and restricting access to pages based on authentication should be implemented in the Next Application. I can see two approaches to handle page-level access for authenticated users:
- Create a field on your page template that indicates if the page is visible for anonymous users or for a particular user group. Check it in your head app. In that case, CM users control which pages require authentication and which do not.
- Using middleware in NextJs and controlling access to specific routes based on the user state.
There is also a good thread on StackExchange about this topic.
6. Only customize XMCloud if it is absolutely necessary
It’s more likely a SaaS product. Customization is allowed on the CM instance. That means you can still write your own C# code and deploy it to XM Cloud, but you should avoid it and try to leverage OOTB features for your requirements. (see more examples below). On the other hand, there are pipeline customizations that do not make any sense in the context of XM Cloud anymore, e.g custom item resolver. This is something that you need to handle in your head application. Just keep your CM simple.
7. Consider using the Authoring & Management GraphQL API for content automation instead of the Sitecore APIs
The Authoring and Management GraphQL API was introduced in Sitecore 10.3 and it is also available in the XM Cloud. It offers CRUD operations on items, media, templates, and various management operations such as indexing, archiving, publishing, checking job status, etc. It’s upgrade-safe, so you can avoid writing your own C# code and continuously keeping up to date during platform upgrades.
8. Consider workflow webhooks instead of custom workflow actions
The event handler-related webhooks were introduced in Sitecore 10.3 and it’s also available in the XM Cloud. Basically, I can say the same as in the previous point. Try to leverage this OOTB feature as much as possible and avoid implementing using any logic with C# in the backend.
9. Sitecore Experience Edge — Webhooks
If you are using Experience Edge, that means you can say goodbye to Sitecore Event Handlers if you want to perform something after publishing. If you are using SSG, you might want to regenerate some pages in your head application after you published your content to Experience Edge. This is something that you can achieve by using Experience Edge Webhooks.
There is a must-read article by John Rappel about this topic:
10. Sitecore Experience Edge vs Component Patterns
Due to the Experience Edge architecture and its behavior, you really need to pay attention to how you design your components. e.g one of the best practices by Sitecore for Experience Edge is that you should avoid putting global data into the layout service’s output for pages. e.g a Footer component where you use a single data source item for every page, the component using Datasource Rendering Content Resolver so it is part of the layout service output. If the author modifies the data source item for this component you will end up in a full site republish, since only the layout service snapshot is stored in Experience Edge, the output is not being calculated there. Another must-read article from John Rappel on this topic:
11. Utilize Headless SXA
The official starter foundation utilizes headless SXA. It’s a set of features that makes everything easier, including managing multisite scenarios, and comes with many great built-in features that will speed up your work. It’s the main and best approach for building sites in XM Cloud.
12. Use the new tools and interfaces in XM Cloud
There are many new tools available in XM Cloud, such as Components (helps marketers and authors to create components without dev effort), Explorer (similar to Content Editor), and Pages (It’s basically a cloud-native Horizon). Experience Editor is still there, but personally, I will stick to Pages from now.
13. There is a life beyond Vercel
If you already worked on a Sitecore XM + Experience Edge + Vercel project and you are starting your XM Cloud project, you might don’t know that there is an internal editing host in XM Cloud. It’s not configured for serving live traffic, but it’s configured for authoring operations and integrates with Experience Editor / Pages. Your public site still should be hosted somewhere else, e.g. on Vercel.
Edge case scenario, but it is possible to use static export in NextJS and host on an S3 bucket or somewhere else. (Note: e.g on the S3 bucket you lose advanced NextJS features, such as API Routes, Middlewares, etc.. but due to the internal editing host you can still use authoring tools in XM Cloud (Experience Editor/Pages) because it’s a host that runs within the XM Cloud.
There are many things to consider when picking your hosting options. You can watch the video below for some alternatives.
Summary
I hope you enjoyed this article and helps you in your first XM Cloud project. Leave a comment about what other differences you can see in XM Cloud compared to the classical Sitecore XM/XP MVC-based world.