High Score Labs News • May 9, 2023
In this article we will brief about the development process with XM Cloud and its gradations. Considering you’re either familiar with the traditional way of Sitecore development or at least get some basic understanding of the process.
In order to identify the difference in the development, let’s quickly recap architectural features of XM Cloud that affect:
- There are no more Content Delivery (CD) servers available
- Content gets published to Sitecore Edge
- It enforces headless development only
That means we now have a “head” web application running on a Rendering Host. That would be most likely built with Sitecore Next.js SDK – using Next.js on top of React with TypeScript running on a Node-powered server.
Next.js is a framework created by Vercel that is built on top of the React library, designed to help developers build production-ready applications with little need for configuration and boilerplate code.
As a natively headless platform Sitecore allows using any other framework or technology, like Vue, Angular, or .NET Renderings, however, if React is your choice then Next.js SDK will offer you lots of features available out of the box, including:
- Layout Service fetching and mapping
- Components Factory
- Powerful routing mechanism
- Placeholder Resolver
- Field Helper components
- Multi-language support
- Experience Editor support
- Sitecore Analytics support
Follow Sitecore documentations for more details - documentation.
All Headless – A headless architecture consists of a back end with a layer of services and APIs and a front-end/client/user-facing application. The front-end application, or presentation layer, retrieves data from the CMS using API endpoints and uses that data to populate or hydrate the markup it generates.
Without having CD servers any longer, there is no place to execute HTTP request pipeline extensions. Experience Edge provides just raw published data in a headless way, there is no place to apply any logic. But what if you need to modify a request, for example? Since, all that logic gets moved to a headless application, since changes will need to be made in the hosting environment for the client application.
Any other integrations or personalization previously taken place on a CD server should be refactored to work with the headless application at the Rendering Host. It is recommended to use out-of-process API-based integration as much as possible to maintain loose coupling.
- Fully Local development requires containers running on a Windows-based environment and you need to have a valid license file to run it. If running on a client version of Windows (say, 10 or 11) make sure to reference 1809-based images in your .env file.
Once you run it, you may see a list of containers – it is pretty similar to what you can find with the classical XM platform:
The main container is called CM with XMCloud.
There is a Solr container used for internal purposes, a container with a SQL server, and init containers for both of them.
Another important container is Traefik – the one that accepts and distributes external traffic. One of the most frequent errors occurring while trying to set up local containers is that developers often already have a running web server (for example IIS) that occupies port 80, preventing Traefik running in a container from exposing its own port 80, so that it errors out.
The rest of the containers are providing rendering hosts with headless applications
The principal difference of local container development is that instead of using Edge from XM CLoud, your rendering host will connect to the GraphQL endpoint of the CM instance which features the same API as cloud-based Experience Edge