What is Headless?

The concept of headless is part of the MACH architecture. In a headless solution, you will output JSON. Just data, the CMS doesn't know anything about the implementation of this data. The consumer of the data is responsible for the presentation. Decoupling content and presentation is the foundation of headless. The content is available through an API.

Headless differs from the MVC way of working with Sitecore. As I sketched in my previous blog we used Razor views to mix HTML, CSS classes, content from Sitecore, and other data. This was a coupled way of working.

In contrast, in headless the presentation and content are decoupled. But I am aware there is more nuance needed. For example, you probably asked yourself the question:

How about the Layout, Horizon, and the Experience Editor, that's presentation, isn't it?

Yes, correct. In Sitecore, we know the concept of a layout. A way of designing a page with components in specific placeholders. How does that fit into a headless approach? In this blogpost, we will answer that question by taking a look at the two approaches of headless.

1. Headless
2. Hybrid Headless

Headless

There is a known unwritten rule for Sitecore developers to avoid setting content directly on a page as much as possible. With a decoupled content repository you can relate and reuse content from multiple locations. This concept already looks like a kind of headless approach!

In case you needed to expose data from Sitecore, you could use the Item Service API or build a Custom API. Does this mean Sitecore always has been decoupled? According to this blog it does.

If you look at it this way Sitecore has always been headless. So there is no magic involved, no silver bullet, no tool that suddenly fixes all problems. Headless is embraced by Sitecore from the beginning. So what is all the buzz about? Why is headless suddenly so hot right now?

There is no magic involved, no silver bullet, no tool that suddenly fixes all problems. Headless is a concept which is embraced by Sitecore from the beginning.

It's the evolution of the cloud and the way we are building websites. Think about component-based libraries, serverless edge functions, edge caching, etc. A lot of buzz words, but the takeaway here is, these toolings and concepts empower you to build incredible performant and scalable websites. So headless is always been possible with Sitecore, but there is a catch, these APIs will not return any information about the context and layout of a Sitecore Item. For these functionalities, you need the hybrid approach.

Hybrid Headless

The Layout Service is part of the Hybrid Headless approach, the context and editing functionality is preserved. With the Layout Service API, every route request will result in a response containing context, route, and placeholder data. In headless terminology a page is often referred to as a route.

A Layout Service route request will result in a response containing context, route, and placeholders data.

With the hybrid approach, you are free to interpret this page structured data the way you want. This is in line with the Composable DXP concept. But of course Sitecore has released several packages which already are capable of interpreting the Layout Service, and inject the response in your frontend components.

Headless Overview

With all the pieces of the puzzle together, the headless architecture will look like the simplified image below. This is my mental model to comprehend the headless way of working.

Per component or use case you decide which headless approach fits best. You could even use both by, for example, using the Layout Service response for requesting more data via a connected GraphQL query. On the right, you see the Composable DXP, all kinds of APIs which easily integrate into your app. I will cover the frontend layer another time.

It's time to explore the Layout Service more. We take a deep dive into Content Resolvers and Integrated GraphQL. Let's go!