Back in the early days, most web content management systems managed only websites—websites that were browsed using only desktop browsers. And for the first few years, CMSs were the best way to manage those sites. They handled content management, content delivery, and content presentation, all in one system.
But as the web has evolved, and as mobile, IoT, and virtual assistants like Alexa and Siri and Cortana have become more ubiquitous, presenting content only on a web page ignores the larger opportunity that a more mature web offers. So, a few years ago, we saw the rise of “headless CMSs.” These systems were built for the sole purpose of organizing content and then delivering it through a web service (RESTful services) for pickup by other systems. They had nothing to do with content presentation (the "head")—so developers were needed to render the content for different devices and applications.
Headless architecture can organize and deliver content, but isn’t involved in content presentation.
A third, hybrid approach to CMS architecture decouples content management from content delivery and presentation, separating content functions and storing content as components, each with strict responsibilities and tasks. Storing content as components rather than as whole pages allows different parts of a page (the components) to be presented on different channels—it gives you the flexibility and efficiency of creating your content once but using it many times.
Our decoupled foundation
At Sitecore, we’ve always believed content should be stored at a central location in the system and be reusable anywhere without being limited to only being presented on a single page. This philosophy has been at the heart of Sitecore from our beginnings as a company. Save your content once as a component, and let a separate process handle how and where it’s presented.
And that is exactly why we always had a decoupled presentation layer that can deliver a personalized digital experience.
When we launched the Sitecore® Experience Platform™ (XP) 7.5, we introduced the Sitecore Services Client, which is a services API layer that uses a RESTful interface to communicate with channels. Here’s how it works: When a request comes in (say, from a mobile device), Sitecore translates the request to a search query for Sitecore Content Search, which returns the requested information to the device.
Now, Sitecore XP 9 introduces an OData layer next to the existing services API—the benefit of OData for querying Sitecore for content is that, as an industry-standard protocol, it lets developers ask for the specific data they need (vs. getting it in one format) and could lead to lower implementation costs since it requires no custom development.
Using the content that comes from the Sitecore Services Client, users can enrich a variety of channels—from JavaScript applications to mobile applications to any IoT-connected device.
The headless hurdle: Personalization
The problem with the “headless API” that the Sitecore Services Client delivers is that headless configurations don’t support delivery of personalized content. Your content may live on an IoT-connected device, but you can’t receive data about how users are interacting or push out personalized content just for individual needs.
But there’s good news. When we launched the Sitecore® Experience Accelerator in 2016, we delivered a toolkit with more than 70 standard components that you can use to create websites more quickly and without any coding. And last year when we released version 1.5 of this toolkit, we introduced two ways of delivering personalized content through a RESTful API.
Within the Sitecore Experience Accelerator, you can transform content into the JSON file format by dragging and dropping JSON components on the page. (The benefit of JSON is that it strips all visual formatting from the content so other “nonvisual” devices—think Alexa devices—can consume it.) You have full control over the JSON structure and which data is displayed. In addition, you can add advanced features like personalization and testing to the JSON components.
Sitecore XP 9’s Layout Service decouples content delivery.
Another approach we implemented in Sitecore XP 9 is the Layout Service. This is a service layer that works on top of the Sitecore presentation layer. When Sitecore constructs a webpage, it requests and combines multiple presentation components to render a page. For each of those components, it uses the context for which the request came in (geo-location, device, time, user, etc.) and then retrieves the content and presentation. Once those are loaded, it checks if there are any personalization rules or tests that need to be applied to that specific component for that specific visitor. Then finally it assembles all those individual components that make up a webpage. The Layout Service inserts itself right before the web page is rendered by converting all the presentation components to JSON. In this way, all personalization and testing rules are being applied to the JSON-formatted content.
In addition, the Layout Service passes along the context in which the request has been made, meaning that the request is being registered in Sitecore for that specific visitor. This way, Sitecore has full analytics over all the requested content and can use that to personalize even more effective experiences.
Sitecore JavaScript Services
Finally, Sitecore JavaScript Services (JSS), which is currently in Technical Preview, is a complete SDK for JavaScript developers that allows them to build full-fledged headless solutions using Sitecore and modern JavaScript UI libraries and frameworks.
JSS is a toolkit and offers multiple ways of delivering headless implementations with Sitecore. Front-end developers can use the JSS SDK to enrich their JavaScript applications with some Sitecore “sprinkles” to enable full integration with Sitecore XP. Or developers can create their JavaScript application first—without being dependent on Sitecore—and import it later into Sitecore. The benefit is that front-end developers can create headless Sitecore apps with no knowledge of Sitecore.
Everybody wins
Content authors can manage these JavaScript applications with the Sitecore® Experience Editor as they would edit any other web page—including advanced features like testing and personalization.
IT departments and developers can deploy and host the headless application in a manner decoupled from Sitecore. Any server running server-side JavaScript can host the application while maintaining analytics and personalization features.
Front-end developers, content authors, and IT departments all benefit. Most important, your customers interact with application content that’s personalized for their needs. Everybody wins! Learn more about Sitecore as a headless CMS.
Mark van Aalst is a Technical Evangelist at Sitecore. Find him on LinkedIn.