The Basics of Headless
“Headless” has been a buzzword for more than a few years in the CMS space, but what exactly is a headless content management system?
In short, content management systems (CMS) have traditionally handled content management and rendering (creating markup and serving to web browsers or other clients). A headless CMS only handles content management and provides an API for other systems to consume that content. This allows the rendering aspect to be handled by third-party systems or tooling. Essentially, content that was traditionally destined for the browser can instead be consumed by browsers (via JavaScript applications) as well as desktop applications, mobile apps, digital print media, etc.
Sitecore has always provided headless capabilities to some degree (thanks to the Item Service API), but its implementation is overly simplistic in scope and requires additional architecture and development to be useful.
JavaScript Services (introduced with Sitecore 9) facilitates a true headless-first approach for Sitecore development, allowing content, presentation, and personalization to function against a native headless API.
Sitecore is Going Headless – Again
With Sitecore 10, headless development is finally a first-class citizen. Sitecore now provides a robust API for loading content, presentation information, personalization, and more from the CMS in a client-agnostic way.
Browser-based applications can consume these APIs to enable rich, content-driven applications and allow front-end developers to interact with Sitecore without having to learn the entire backend stack tech. JSS was just the beginning – with Sitecore 10, developers can now implement ASP.NET Core applications that implement rendering and presentation logic in a headless manner.
For other server-based applications, a rendering host can be built to consume, render, and serve content. A rendering host is an ASP.NET Core application that utilizes new, lightweight Sitecore libraries and APIs to retrieve content from Sitecore and render it. Renderings hosts can implement any other logic, functionality, and customization needed by a potential front-end. In short, a rendering host application handles the presentation work while Sitecore handles content management.
Rendering hosts utilize two lightweight APIs for handling content: the Layout Services Client and the Rendering Engine SDK:
- Layout Services Client is responsible for loading content, presentation, and other information from Sitecore via the headless API
- Rendering Engine SDK provides an API for consuming data from the Layout Services Client to render content; also handles some request route mapping and view configuration
What about JavaScript Services?
One final note: how does JSS play into this new headless paradigm? The new headless experience is actually built upon JSS, so with Sitecore 10 we get a terminology update: “JavaScript Server Components” will be known as “Sitecore Headless Services” from now on. The client-side pieces of JSS aren’t going anywhere.
Finally, don’t fret, MVC folks! While headless is a great option for organizations looking for additional implementation and scaling flexibility, Sitecore 10 continues to work great with the traditional MVC stack (sorry, Web Forms, but my personal recommendation: your time is up).
