Controlling Your CX with a Headless CMS: Kyle McKenzie [Podcast]
In this episode of Coffee + Commerce, Kyle McKenzie, our lead software engineer at Fabric who is actively developing our headless CMS called Experience Manager (XM), breaks down headless CMS software.
He discusses how businesses can leverage a headless CMS to modernize their tech stack, scale e-commerce across channels, and control brand identity and customer experience (CX) as they enter into new sales channels.
Listen to this episode on your favorite podcast player.
Questions asked and answered in this episode include:
- 1:07 What is a traditional CMS vs headless CMS?
- 2:27 What are e-commerce use cases for headless CMS?
- 4:30 How do marketers and merchandisers use a headless CMS?
- 5:51 How do you use a headless CMS to publish experiences on different channels?
- 7:50 When is the right time to implement a headless CMS?
- 9:09 Which technologies complement a headless CMS?
- 11:27 How do you get started using a headless CMS?
What is a traditional CMS vs headless CMS?
1:07 Robert Gibb
So for people who don’t know what a headless CMS is, how would you describe it to them?
1:13 Kyle Mckenzie
To start to answer that question, I want to tell you what a traditional CMS would do, one that actually gives you the head and that’s going to provide a whole set of facilities to give you a render process. So they’re going to actually create your HTML. They’re going to create the JS that’s driving the events and the interactions, and it’s going to serve all of that to you over the Internet.
That pushes the control away from the customer and towards the provider. And a headless CMS actually flips that contract around, where all of the control is given back to the customer, and it’s relinquished from the provider.
So in the headless scenario, instead of getting pre-rendered content in HTML, and with JS and your CSS, what you’re actually going to get is HTTP REST API responses, and those are going to carry JSON bodies, and JSON is infinitely flexible, and you can make it provide you with any shape that you would need as a consumer, and that can power a variety of different types of components and types of experiences across different mediums.
2:14 Robert Gibb
That’s an awesome explanation. I’ve never heard it so succinct before. Usually, you get this huge explanation of, oh, it’s just decoupling the frontend from the backend, and then you handle the frontend. So I love how you put it there. So going off of that, what are some of the e-commerce use cases for headless CMS?
What are e-commerce use cases for headless CMS?
2:33 Kyle Mckenzie
I think right out of that, you take the control paradigm, and you want to think about how that’s enabling you. So if you look back in the last seven, eight years, we’ve seen this steady trend away from a primarily brick and mortar commerce scenario, and we’ve endured constant and rapid changes. And that means the marketers need to be more agile than they’ve ever been.
If you’re giving the control to a provider, then your ability to update your brand, your ability to update your event system that’s driving some of the interactions on your mediums, is extremely limited, and you’re in a very reactive position, whereas when you’re owning that part of the source code, you’re able to be extremely reactive, and you can scale up and provision resources as you need them within your teams.
And you can very quickly make those changes that you need to be able to respond. Usually, the use case isn’t specific as the underlying need for the CMS. Usually there’s a driver where you’re really wanting to move away from that inflexible situation, you want to move towards a headless scenario.
The use cases is a harder one to answer, because you’ve got so much flexibility that you can drive almost any e-commerce experience. It’s not like you’re pigeonholing yourself to just a single channel or an omni channel experience, or just doing mobile, because, again, at the end of the day, you’ve got a REST API and anything that can connect to the Internet can become a client of the REST API, and that gives us this really broad set of capabilities to power content across different mediums.
4:10 Robert Gibb
Yeah. So it seems like it comes down to making a headless CMS that works for you. So if you have something like Fabric Experience Manager, obviously there’s infinite opportunities to go into different channels and create different experiences. But for merchandisers and marketers, they need to actually use the system.
So how do developers and people who are implementing this headless CMS—how do they make it usable for business users like marketers and merchandisers?
How do marketers and merchandisers use a headless CMS?
4:40 Kyle Mckenzie
One of the things that Fabric does that’s pretty different from what I’ve seen before, is that at the very beginning of the process, we have the marketers sit down with a design team and chart a course for the components that the marketers are going to be using.
The marketers are able to give their requirements directly to the people who are going to design the components that they’re going to be interacting with and create the interfaces for them to update through XM, and that kind of collaboration can really set a direction for success for the lifetime of a set of components, through a content management system.
5:14 Robert Gibb
So if I’m putting content into a headless CMS like Fabric XM, and I have all these different ideas for different channels I want to tap into. So say like, Netflix has this new offering where you can insert your products into the actual movie or TV show and create that sort of experience. And then on the other side you have more of a traditional desktop / mobile experience. Do you put the content in the headless CMS once and then it extends? Obviously, it wouldn’t be automatically, but, how does that process work when you’re working with different channels for commerce?
How do you use a headless CMS to publish experiences on different channels?
5:51 Kyle Mckenzie
I’m going to answer this with a look into the future of templating. That’s a pretty classic use case for using a content template, and a content template allows you to create certain components with a pre-configuration that are going to persist across many different use cases. It could be different channels, it could be different segments. But the idea is that you’re able to preconfigure some of them, and then you add the flexibility that can be overridden in the future. And that gives you the ability to power that sort of e-commerce experience.
6:23 Robert Gibb
And those templates. So take Fabric XM, for instance. What are those built with? Which technology is that built with? Is that where React comes into play?
6:34 Kyle Mckenzie
Inside of XM, we’re going to be technology agnostic. And one of the core tenets of what we do is that we don’t want to concern ourselves with your stack, and we want to give the customer the utmost flexibility in how they’re consuming and how they do their own implementation. So we stick purely to the principle that we’ll provide a REST API with JSON responses, and we don’t have to say anything about that.
Internally, we’re going to be concerned with building the templates inside of a format that translates into that JSON structure, so that you’ve got something that’s extremely predictable and consistent. You know what our API is going to return, and then you’re able to take your content definition that you’ve defined, and apply that to your response to understand where your content goes.
7:25 Robert Gibb
Got it. And then for people thinking about headless CMS. So they’re using a traditional CMS, either through a big commerce platform like SAP Hybris, or even like Shopify and Shopify Plus. And they’re hearing all this talk about headless CMS. How do they know whether they should start investigating in a headless CMS or not? How do they know if it’s worth their time to use and actually implement?
When is the right time to implement a headless CMS?
7:50 Kyle Mckenzie
I really want to bring this back to the control paradigm that I introduced at the beginning because I think that’s going to be the point where you’re starting to see the restrictions of a traditional CMS and you might want to consider headless.
If you feel like you’re not able to be responsive enough, if you feel like you’re trapped within a system and you don’t have the room or the flexibility to get the kind of solution that you’re looking for to the problem, that’s the point where it becomes a really good idea to start to investigate how headless could change. There could be different challenges as you start to look into headless. So if you’re an older MVC style platform, that can be a different challenge because you might also be looking at how can I modernize my technology stack?
Modernizing your technology stack is a great time to start to look at being headless, because the headless paradigm works so well with a component-based architecture. So if you’re moving into that kind of architecture, it’s really a technologically beneficial time, and you can save a lot of engineering costs if you do them both together.
8:53 Robert Gibb
So when starting to use a headless CMS, or starting to explore headless CMS, what are the core technologies that should also be considered to create experiences that are very agile, and they can span across platforms and channels?
Which technologies complement a headless CMS?
9:09 Kyle Mckenzie
So let’s take this in a few different pieces. If we’re thinking about the web and let’s start there. The very first thing you’re going to want to think about is your SEO performance. If your customers can’t find your products, they can’t buy your products. And that’s really where we have to start and finish. So you’ll always want to end up on something that’s going to be server-side rendered. There are lots of other performance tuning metrics that we can dive into, but we want to be server-side rendered.
From there, we have to find a framework that is going to support our needs as the customer, and that could be something where we want to be component-based like React. It could be something that’s going to be a little bit more flexible, like a Vue. It could be for internal reasons, we’ve got other systems on Angular and so we’ve got some in-house knowledge, and we don’t have to go retrain everyone on the new framework.
Those are all good reasons to pick a certain stack, as long as it conforms to that SEO restriction where we can render it on the server side, we’re going to be pretty happy with the solution that we end up with.
Now if we go across mediums and if we want to look at mobile, you have to make the fundamental engineering decisions about, do you want to commit to one technology stack per device? Do you want to be doing Swift for iOS, and do you want to be doing Native Android? And then if you don’t want to do native, maybe you want some code reuse. And that would be we’re looking at something like a React Native or a Flutter might fall in.
And these are decisions that you’re going to have to make based on your resources, based on the amount of resources you have, and the kind of optimizations you want to get eventually. These are very engineering-specific decisions, and they’re not necessarily marketer-specific decisions. Whatever decision you end up choosing, you’re still able to consume a REST API with the JSON response, and so you’re still able to tap into that flexible content service. And again, you’re not going to be hindered by moving in the direction of a headless solution.
11:10 Robert Gibb
Okay, so if your tech stack is currently spread across legacy systems, some custom systems, some microservices, and you’re using a bunch of different technologies, whether it’s React or something else, how do you get started with the CMS—the headless CMS?
How do you get started using a headless CMS?
11:27 Kyle Mckenzie
The first thing you want to do, is you want to take a good, hard look at your systems, and you want to figure out which parts of your customer-facing systems are running on which technologies and how to group them out. So if you’ve got a bunch of MVC services, you can start to think about bunching those together and put them in a bucket. If you’ve got some Angular services, you can put those together. If you’ve got some React services, you can put those together.
The easiest way to start to integrate headless into what your stack is, is to start with the component-based architectures. It’s a really natural fit, and you can start off by configuring as simple as a single component to work with the CMS, and that can give you a very gradual learning curve. And you could add in incrementally one or two or 10 components at a time, to give your marketers more control. That gives you a really gentle introduction to headless CMS, as opposed to having to do a complete rewrite and completely dive into something that’s brand new.
If you move into your older MVC, you run into some trickier patterns because generally you don’t have dynamic renders. You’ve got preset views, and consuming this data into that becomes a little bit more cumbersome and there ends up being a bit of a re-architecture. So I generally recommend to leave those for the very end, because that’s going to be a bigger problem and a little bit more resource consuming, whereas you can get a lot of benefit very quickly if you pick one of your more component-based systems.
Tech advocate and lead editor @ fabric. Previously StackPath, Upkeep, StackShare, MaxCDN.
Related Content
