What is Headless Commerce? Pros, Cons, Integrations & Solutions

Over the past several years, many ecommerce brands have rearchitected their technology stacks according to an approach referred to as “headless commerce.”

Headless commerce refers to the decoupling of the backend commerce logic from the frontend user interface, or presentation layer. The decoupling of the commerce engine from the frontend allows brands to create custom user experiences that increase the percentage of shoppers that convert into buyers.

Going headless also provides brands the opportunity to speed up their time to market. Gartner estimates that by 2023, organizations that have adopted headless commerce will be able to launch new features and functionality to market faster than 80% of their competitors.

In this article, we provide an overview of headless commerce as well as discuss its advantages and drawbacks. We cover:

  1. Headless commerce 101

  2. Benefits of headless commerce

  3. Drawbacks of going headless

  4. Headless commerce integrations

  5. Headless commerce solutions

Headless commerce 101

Headless commerce is a new way for brands to architect their technology stack. In this section, we discuss what makes headless commerce different from a traditional tech stack and how this new architecture facilitates new approaches to streamlining internal operations and improving the customer experience.

Traditional vs Headless

Traditional, or monolithic, tech stacks tightly couple the backend commerce logic with an online storefront. Shopify and BigCommerce, for example, make available to ecommerce brands an online storefront for customization in their respective admin panels.

While your internal teams have access to an intuitive interface to create new pages and updating existing content, creating custom user experiences can be challenging to implement as it requires developers to not only make changes to the frontend code but also the backend commerce logic.

When you go headless, however, you give your brand the ability to make large scale changes to your frontend without impacting any backend code. This gives your developers and brand more flexibility with the updates you can make to the frontend while decreasing the time to launch new functionality and features to market.

What makes headless commerce possible is the reliance on an Application Programming Interface (API), which serves as a programmatic interface that applications use to exchange data between the frontend and backend. APIs have revolutionized how technology stacks are implemented and have given rise to the Jamstack.

Jamstack

The first three letters in Jamstack stand for JavaScript (J), APIs (A), and Markup (M). Jamstack technologies are specifically optimized for page speed and consuming data from a backend, which makes it an attractive option for brands that are going headless. 

It’s best to give a brief review of the history of web development in order to highlight how novel Jamstack is compared to how websites and web applications have been developed in the past.

Websites were primarily static in the early days of the web. When a user requested a website, a request went to a server which returned pre-built HTML and CSS files back to the user’s browsers. These websites supported very little interaction and didn’t display updated data to the user in real time.

Dynamic websites, which gained popularity in the early 2000’s, supported the ability to display custom content to users. Dynamic websites generate web pages on the fly, or during runtime.

When a user makes a request to a dynamic website from their browser, the request is sent to a server, which responds by pulling information from a database, merging it with a web page template, and sending that webpage back to the user. WordPress is an example of a dynamic website.

While dynamic websites support the display of updated, fresh data, one problem that emerged was the issue of performance. Web pages are rendered by the server during every page request, which results in slower performance during periods of high traffic.

Early attempts to solve this issue resulted in placing a greater responsibility for data requests on the frontend user interface, especially as websites became more interactive. The frontend would make an API request to a database or third party service, reducing the load placed on the server.

Jamstack technology represents the logical culmination of placing greater responsibility on the frontend to make data requests. React, a popular JavaScript library, was initially designed to render websites on the client, or the user’s browser, instead of on the server. This greatly reduced the load placed on the server and made frontend experiences feel fast and performant from the user’s perspective.

Modern JavaScript frameworks, such as Next.js and Gatsby, are built on React and offer static site generation and server-side rendering in addition to client-side rendering. These frameworks give your brand the option to generate your websites as static HTML, CSS, and JavaScript files.

With cloud-hosting providers such as Vercel and Netlify, you can cache these static files on a Content Delivery Network (CDN). A CDN is a global network of servers that stores assets related to your website.

Rather than having each page request hit your server, your shoppers can now receive pre-built web pages from close to where they live. The frontend can still make API requests to the server to retrieve fresh data if any content has gone stale. This greatly reduces the load on the server and delivers your site quickly to customers around the world.

MACH Architecture

The decoupling of the commerce backend and the frontend interface is only one element in a much broader technology stack re-architecture. This is often referred to as MACH architecture.

MACH is an acronym that stands for microservices (M), API-first (A), cloud native (C), and headless (H). In addition to decoupling the frontend from the backend, APIs allow your brand to also select best-in-class cloud-hosted technologies and integrate them into your tech stack.

Going back to our earlier Shopify example, online storefronts are not the only feature coupled with a traditional commerce platform. Shopify also comes tightly integrated with marketing automation features, an inventory management system, and much more.

An API-first approach, however, allows your brand to select custom technologies rather than rely on the features that automatically come with a monolith platform. For example, your brand can select the best Content Management System (CMS) or Order Managenent System (OMS) to integrate into your stack.

Benefits of headless commerce

Headless commerce has been adopted by a number of brands due to how it can streamline internal operations and improve the customer experience. In this section, we break down the reasons why headless commerce produces these outcomes.

Create omnichannel experiences

Traditional ecommerce platforms make available an online storefront that your customers can access on desktop and mobile devices. In the 2020’s, however, shoppers can also be reached on other platforms, such as voice assistants, watches, and other types of IoT devices. Traditional platforms are not designed to reach customers on these devices.

Headless commerce gives your brand the ability to create a custom frontend for any devices. With the use of API’s, your frontends can pull your product and customer data onto any device to ensure you can reach your customers on whatever platform they are interacting with.

Fast page loading speed

Research studies have shown that slow page loading speeds reduce conversation rates. Users get frustrated when a page loads slowly and are likely to abandon your site. The faster a page loads, however, the higher the rates of conversion on your site.

Headless commerce allows you to select your own frontend technologies, which is the primary reason why Jamstack technologies have gained popularity in recent years. Jamstack technologies are optimized for page speed by relying on static site generation and the deployment of your storefront on a CDN.

As mentioned earlier in this article, when shoppers request your site, a pre-built version of your site is delivered to them on a server close to where they live. And with the site built with JavaScript (the “J” in Jamstack) and the browser handling much of the routing, users experience a blazingly fast page load speed.

Greater customizability

The online storefronts made available by traditional ecommerce platforms are based on web templates. There can unfortunately be technical limitations to customizability when working with templates.

And even when your development teams can implement your custom features, your teams may need to resort to workarounds, which can lead to tech debt and lengthening the time to market.

Headless commerce platforms give you greater flexibility to customize your frontend application. You can select the technology you need to create the experiences you want for your customers. You have the flexibility to create custom brand and user experiences that will drive conversions on your storefront.

Faster time to market

Going headless allows your development teams to work independently of each other, which allows your brand to bring new features and functionality to market quickly.

This is in contrast to traditional ecommerce platforms, where development work on one part of the frontend may result in making changes to the backend, lengthening the time to market.

This is not the case with headless commerce as the frontend is decoupled from the backend, allowing your teams to make changes without touching other systems in your technology stack.

Drawbacks of going headless

Going headless may seem like a no brainer given the benefits we discussed in the previous section. But there are certainly some drawbacks to consider before taking the plunge into a headless architecture. In this section, we discuss the main cons to headless adoption.

Additional complexity

We’ve discussed the drawbacks to monolithic ecommerce platforms, but one advantage to a traditional platform is that your developers have to deal with less complexity. Since all your features and functionality are tightly coupled, your tech stack requires less effort to maintain and is easier to manage.

That is not the case when you adopt a headless architecture. You expose more touchpoints to potential failure when you decouple your frontend from your backend and rely on APIs to integrate other systems into your stack.

If a third-party service changes their APIs, your developers will have to update all the frontend and backend layers that consume data from that service.

Your developers will also need to have contingency plans for when a service goes down by determining how that disruption is presented to the user on the frontend. They’ll also need a process of working with the service to get it up and running.

Additional developer resources

Given the increasing complexity of going headless, your brand will likely need to increase their spending on development resources. You’ll need additional developers to not only build and maintain your frontend but also maintain any other technologies associated with it, such as your API orchestration layer and Backend for your Frontend (BFF).

Building your frontend can cost anywhere from 50K to 500K depending on the scope of the project. You’ll also have to expend additional resources on developers to manage and maintain your frontend. As a result, you’ll most likely have to increase the number of in-house developers or retain an external agency.

More software procurement

When you go headless, you have the opportunity to select best-in-breed technologies to power your internal operations and customer experience. Your brand can select a Content Management System and Inventory Management System that suits your unique business and technology needs.

A downside to integrating all these technologies into your technology stack is that your colleagues may find themselves overwhelmed with the procurement process. You could find yourself negotiating and approving third party services with over a dozen different vendors.

This could be overwhelming for your organization especially if you don’t already have a dedicated procurement team.

Changing internal operations

Adopting a headless commerce platform will require your content and marketing teams to change their internal processes for creating and updating content, as well as launching new landing pages.

Traditional ecommerce platforms often come with an intuitive drag and drop interface that gives your teams control over creating custom experiences and updating content. When you go headless, however, you take that functionality out of the hands of your internal teams.

Your content and marketing teams become more dependent on your developers to make changes to the customer experience in terms of updating and creating new content.

This dependency can be mitigated somewhat by adopting a headless CMS or Frontend as a Service solution. These solutions often come with a page builder or visual editor that give your teams greater control over publishing content and creating new page experiences.

Headless commerce integrations

As has been mentioned throughout this article, headless commerce is part of a broader decoupling of various functions from your commerce engine, often referred to as MACH architecture. In this section, we take a broader look at the ecommerce ecosystem by examining several potential services that your brand can integrate into your technology stack.

Content Management Systems

Traditional ecommerce platforms come with a native Content Management System (CMS). These CMS’s are fairly bare bones in most cases. They don’t come with the capabilities to structure your content in ways that accommodate your business and content needs.

This is where a headless CMS can benefit your brand. Content modeling is a key offering of most headless CMS platforms. When you want to present your content on different platforms, such as voice assistants and IoT devices, you need to model your content differently. 

Traditional platforms require you to structure your content as web pages. Headless CMS platforms, on the other hand, allow you to model your data as you see fit and expose APIs that allow you to consume and display your content on any platform.

Many headless CMS platforms also come with integrations to your commerce engine. These integrations allow your content and marketing teams to weave product information into your content to increase brand awareness and convert shoppers into buyers.

Frontend as a Service

A frontend as a service platform (FEaaS) provides your developers with cloud based modules, UI components, and other tooling to more quickly launch and maintain a highly performant frontend. This serves as an alternative to creating an entirely custom frontend with a popular JavaScript framework such as Next.js and Gatsby.

FEaaS platforms help reduce developer cost and increase time to market. With prebuilt UI components and middleware tooling, your developers can get a jump start on development and launch your frontend quicker than building a custom frontend from scratch. FEaaS also handles deployment and hosting, freeing up more time for your developers to focus on innovative features and functionality.

Several FEaaS solutions also make available a page builder for your content and marketing teams. This functionality gives your internal teams control over previewing and publishing content, which in turn frees up additional developer resources.

Product Inventory Management

Product Inventory Management software (PIM) allows you to manage and update your product catalog. While traditional ecommerce platforms come with a PIM, when you go headless, you give your brand the flexibility to adopt a best-in-breed PIM.

Adopting a separate PIM solution may be useful for your brand if you have a large number of products or product variants, or just need more complex filtering and search capabilities. Just like adopting a headless CMS or any other technology, a separate PIM solution may provide unique features and functionality that are better suited to your business and technology needs.

Headless Commerce Solutions

Headless commerce solutions come in two flavors. One type are traditional ecommerce platforms that have made your data accessible via APIs so your brand can decouple your backend from your frontend. Another is API-only solutions that don’t come with a “head” and are specifically designed for headless commerce. We review both types of platforms in this section.

Shopify

Shopify is the market leader when it comes to traditional commerce platforms, garnering over 25% of the ecommerce platform market. In recent years, going headless with Shopify has never been easier as it has released new features and functionality that supports brands that desire to decouple their frontend from their backend commerce engine.

Shopify’s Storefront API makes all your product, order, and customer data available for consumption by your frontend applications. The Storefront API is available using both REST and GraphQL protocols. Shopify makes the Storefront API available to brands at all price points.

The Shopify Plus plan, however, which is ideal for midsize to large enterprise companies, comes with additional features to support a headless architecture. One noteworthy feature is Multipass, which allows users who are logged in on your custom frontend to remain logged in when redirected to the Shopify checkout page. This feature creates a better experience for the user by pre-populating the checkout page with shipping and credit card information without the user having to sign in a second time.

Commercetools

Commercetools is an API-only headless commerce platform specifically designed for midsize to large brands who want to go headless. Launching their product in 2010, they are a pioneer of the MACH architectural pattern.

Their APIs are extensive in that they support product, order, and customer data using both REST and GraphQL protocols. Your brand can use their full suite of APIs or instead use them à la carte, integrating other services into your tech stack, such as your own Customer Relationship Management (CRM) solution or PIM.

Commercetools Frontend is a Frontend as a Service offering resulting from the acquisition of Frontastic in 2021. Commercetools Frontend makes available to your developers customizable UI components, an API orchestration layer, and deployment and hosting options.

Your content and marketing teams can publish and update content using a page builder. This feature allow your developers to focus on innovation while giving your internal teams the autonomy to create custom user experiences

BigCommerce

BigCommerce is another popular traditional ecommerce platform that has exposed APIs for brands that desire to decouple their frontend from their ecommerce backend. BigCommerce makes available 92% of your data via API, which makes going headless with BigCommerce a viable option for brands.

Various integrations and templates exist to accelerate development and quicken time to market. In addition to starter templates based on popular JavaScript frameworks such as Next.js and Gatsby, integrations with popular CMS solutions such as WordPress and Adobe Experience Manager are also available. BigCommerce’s One-page checkout is publicly available as a template for brands that want to customize their checkout experience.

BigCommerce’s robust APIs are available using the REST API protocol. As of the date of this article, a GraphQL API is only available for your brand’s product catalog, although BigCommerce has stated in their documentation that extending their GraphQL protocol to include additional data objects is on their product roadmap.

Bottom line

Headless commerce offers brands a better customer experience with faster page speed and more customized experiences while also giving your developers the ability to launch new features to market more quickly.

But it’s certainly not the right option for every brand.If you’re a midsize to large enterprise brand with existing developer resources and a well defined procurement process, then a headless architecture probably makes sense for your brand.

But if you’re a smaller ecommerce brand with fewer developer resources and expertise, then sticking with your existing traditional ecommerce platform may be the better bet.

Commerceworm logo

Get articles directly sent to your inbox!