Headless Commerce: Delivering powerful content-driven commerce experiences
Headless commerce — or headless eCommerce — is an API-first commerce architecture where the front end and the back end work as two separate systems connected only with APIs.
In other words:
There's no single "platform" the architecture runs on that powers both the front end and the back end.
Instead, a host of different solution providers power each.
The vendors that serve the front end focus on delivering the best-in-class experiences to consumers no matter what screen, channel, or device they're engaging with: a website, a mobile app, or an IoT device like an interactive kiosk.
Likewise, on the back end, another set of vendors work to deliver services like billing, inventory management, customer support, cataloging, fulfillment and others.
And ALL the data orchestration between the vendors happens via APIs.
Let's now see in detail what headless commerce is all about. In this guide:
- Demystifying the headless commerce architecture
- The benefits of a headless commerce architecture
- Building a headless commerce architecture using all-in-one eCommerce platforms like Shopify
- Building a headless commerce architecture with traditional CMSes like WordPress
- Building a headless commerce architecture using a headless commerce solution (and a headless CMS)
- Choosing the right headless commerce architecture for your business
To really understand headless commerce, contrast how a headless commerce architecture works with the workings of a legacy commerce solution — SAP Commerce, for instance.
Below, you can see SAP Commerce's basic architecture. As you can tell, it's "very SAP." Sure, if you use it, you'll be able to use APIs for a host of things and extend functionalities using SAP modules and extensions and so on… but your system will still stay "very SAP" and you'll still stay boxed in the platform's architecture:
With headless commerce, you can break free of these monolithic architectures and the constraints that come with it.
Demystifying the headless commerce architecture
If a headless commerce architecture is "100 percent headless" — yes, there's a degree of how headless a headless commerce architecture can be — it will work solely via APIs.
But as Brandon Shaik, a research associate with Forrester, explains, commerce solution providers can be at different levels of "headlessness."
Shaik explains that a lot of commerce tech stack vendors loosely call their solutions headless, but instead of an architecture that runs fully on APIs, they only offer varying degrees of DECOUPLING of the front and back ends.
A lot of vendors don't actually even need 100% API-driven architectures to go headless and can reap all the benefits of headless commerce with some degree of decoupling.
But why would a merchant want to decouple their front and back ends in the first place?
The benefits of a headless commerce architecture
There are many benefits of going with a headless commerce architecture where the front and back ends are decoupled. Here are a few key ones.
First, you get a development tech stack that supports speed and performance. Most headless commerce architectures let you build storefronts using speed-optimized technologies rather than the standard themes eCommerce solutions come with. This results in experiences that load in a flash. You can also choose different solution providers for your back end ops.
You also get to deliver faster, native-like shopping experiences everywhere. One of the biggest reasons driving merchants to go headless is the need for extending native-like experiences everywhere, i.e., on every touchpoint right from your Facebook shop page to a phablet.
And even unparalleled experimentation and agility. Many A/B tests and conversion rate experiments are simple cosmetic changes to what users see. By decoupling the front and back ends, creating the build for such experiments gets a lot faster. Also, you don't risk breaking the back end as you never "touch" it in decoupled architectures. Launching new features, too, is easy because of this reason, and also because you can build upon any technology that meets your needs.
Above all these, a headless architecture also lets you power your content experiences with a content management system of your choice and not the one that comes bundled with your eCommerce solution provider. Producing better content faster… shipping it sooner… and showing it seamlessly across different channels with a simple API-based system are what you get with this!
So what are your options for building a headless commerce architecture that gets you these benefits?
Well… if you're looking to replatform your business and move toward a headless commerce architecture, you essentially have three options:
Using an all-in-one platform like Shopify.
Using a traditional CMS like WordPress.
Using a headless commerce solution (and a headless CMS solution).
Let’s explore the details of each.
Building a headless commerce architecture using all-in-one eCommerce platforms like Shopify
Seeing the need for headless commerce architectures that help vendors deliver immersive and complex multi-channel and multi-touchpoint experiences, many mainstream eCommerce solution providers like Shopify and BigCommerce launched their own headless solutions.
Cart solution providers, too, started supporting headless setups.
These solutions let you decouple the front and back ends and choose the technologies you want to use at each end and facilitate the working via APIs.
Many merchants go with this option for their building headless commerce architectures as they don't have to start from scratch putting it together. Instead, they get to build upon a robust framework and get full freedom with the technologies they want to use for their different functions.
Here's a zoomed-in view of how a merchant — Koala — realized a headless commerce architecture with Shopify: (Notice that you've two visibly decoupled front and back ends.)
Koala shares that it uses as many as EIGHT different solution providers for its back end ops:
Discounting and promotions
Payments (both online and offline)
Logistics (proprietary solution)
Analytics and reporting
Without a headless commerce architecture, Koala would have had to stick to EVERYTHING Shopify.
Now, you can imagine how the shopping experiences powered by the best-in-class solutions for eight key functions might be better than the ones offered by a legacy solution (no matter how good the legacy solution might be as a whole!).
Also, note that while Shopify comes with its own CMS, this merchant chose to go with a third-party CMS.
In fact, many merchants who take this route for their headless commerce architectures go with third-party headless CMSes instead of the default ones.
And that's because headless CMSes shine at driving content-driven eCommerce experiences. (More on this below.)
Here's another interesting headless commerce architecture that uses BigCommerce but a traditional CMS (WordPress) with it:
Building a headless commerce architecture with traditional CMSes like WordPress
Seeing the need for headless commerce, even classic CMSes like WordPress, Drupal, Magento and others introduced means for headless execution.
WordPress and Drupal did it by launching REST APIs.
Magento, on the other hand, extended support for headless architectures with APIs facilitating integrations, a progressive web app building studio, and support for delivering optimized experiences along multichannel, multi-touchpoint and complex buying journeys via integration with Adobe Experiences (also, its parent company).
Below, you can see how a traditional CMS (Drupal) is positioned in a headless execution setup. You have Drupal sitting at the center of the headless tech stack managing and serving content to support the front end for different devices and channels:
In a traditional setup, though, the back end and the front end would be tightly coupled:
As you can see, more than headlessness, this is simply decoupling of a traditional CMS's front end from its back end.
Decoupling a traditional CMS and trying to make it work in a headless environment can be challenging. The diagram shown below explains how you can achieve different degrees of decoupling for your Drupal traditional CMS if you wanted to go headless with it:
As you can tell, this would involve a lot of re-engineering. And even then, the stack's future development wouldn't be purely API-based.
Because traditional CMSes aren't headless-first by design, many businesses that go headless don't go with decoupling CMSes like above.
Instead, the natural choices for headless commerce architectures are headless CMSes.
A headless CMS is designed for API- or microservices-driven headless commerce architectures and offers the headless commerce stack:
A database for storing the assets at the back end
Functionalities for creating, managing, manipulating, and delivering the content from the back end with support for complex content modeling. (Think personalizations, localization, blazing-fast content deployment, user- and conversion-friendly checkout pages, faster browsing experiences, and easy in-house and user-generated content creation, at scale.)
And APIs that deliver the content to any device or channel or interface (Think desktops, laptops, mobiles, bots, social commerce storefronts, etc.)
Cosmic, our headless CMS, for instance, sits seamlessly at the heart of a headless commerce tech stack and facilitates the content ops — right from production to delivery.
If you wanted, you could use Shopify for the commerce part of your business but Cosmic — with its powerful content management features — for delivering the content experiences.
In such a system, you could also build your own personalization engine (with say, Angular) and bake it right into your content management via the CMS's support for APIs.
Or, you could use Vue JS for building a clean UI and override what Shopify comes with.
Because Cosmic is an API-first headless CMS, you could use it with 100 percent custom front and back ends as well.
But it's not just the API-powered design that works for a headless CMS when compared to a decoupled one for a headless commerce architecture. Its content possibilities, do, too.
In fact, many merchants who switched to our headless CMS solution to power the content experiences in their headless commerce architectures came for our content production and rendering capabilities… and not only because they wanted to use our API to develop a front end with a certain tech stack.
Building a headless commerce architecture using a headless commerce solution (and a headless CMS)
Most of the traditional eCommerce platforms like Shopify and BigCommerce and CMSes like WordPress launched their headless offerings as the need emerged.
Natively, none of these platforms were built for supporting headless commerce architectures.
But 100% headless first commerce solutions like commercetools are.
These headless-first commerce tech solutions are designed from scratch to support microservices-based architectures that can support seamless and futureproof headless commerce setups at scale.
Below, you've one such headless commerce solution where the front end is separated from the back end. You can see the headless commerce solution supporting practically endless "heads" (web shops, social commerce, car commerce, apps, etc.) on the front end and powering all the core commerce operations like managing product, order, and customer data, maintaining catalogs, etc. on the back end:
One thing to note here is that headless commerce solutions are geared more toward the commerce side of the commerce tech stack… and not so much into content experiences.
That's why they offer integrations (API-based, of course!) with a host of headless CMSes with the headless CMSes taking charge of the content experiences.
As you can conclude from the approaches to a headless commerce architecture discussed above, you basically get to choose between 1) adopting progressive decoupling or 2) going fully headless.
Both have their place.
Choosing the right headless commerce architecture for your business
Many merchants don't go with fully headless architectures.
They don't even need to.
Instead, they go with a progressive decoupling approach: one that uses a platform like Shopify (or some of the eCommerce engines traditional CMSes come with) for the commerce part and a headless CMS like Cosmic for the content part.
They end up building a bespoke headless eCommerce website powered by an eCommerce platform and a headless CMS.
The best part is that it still keeps them ahead of the curve.
Shopify and similar platforms offer state-of-the-art commerce functionalities.
And a headless CMS like Cosmic offers robust content production and rendering capabilities. Think unparalleled possibilities for creating beautiful product landing pages, general product pages, help centers, sales campaign collaterals, and much, much more.
The commerce + content functionality you get in such a system is as flexible and powerful as you'd like it to be.
Also, while a headless commerce architecture — in whatever capacity — is a natural upgrade for most businesses, it doesn't come without its challenges. It isn't for everyone either.
The question to move to one (whether it's a purely headless commerce architecture or simply a decoupled one) really comes down to how good you want to get at offering your users personalized, fast, and consistent commerce (shopping) and content experiences across their long and winding omnichannel buying journeys… and improve your lifetime value.
P.S If you're considering building a decoupled or headless commerce architecture, check out Cosmic to power your content ops.