A lot has changed in eCommerce recently. Users expect more from online stores, craving a seamless shopping experience on a fast and easy-to-navigate website. Purchasing behaviors have obviously altered too. People buy things on the go using various devices, including anything from smartphones to voice assistants like Google Home. For online retail sites, this means that it’s high time for some change, as a huge chunk of traffic now comes from other non-desktop sources.
In this article, we’ll gladly introduce you to what is headless eCommerce, explain what it’s needed for. We’ll review how it differs from traditional commerce, its strengths and weaknesses, as well as how it works. Furthermore, we’ll go over the main reasons why opting for a headless solution can be beneficial for your business and in which cases it might not be the best way to go.
As of 2021, the majority of eCommerce stores use a close-to-outdated monolithic approach. Such websites have all their frontend and backend processes closely tied together.
This is the case when the site’s HTML is fully generated in the server and is passed on to the user’s browser. Thus, each time a user opens a new page in the store, the entire HTML (including the header and footer that are the same across the whole website) is loaded from the server. At this point, the browser renders the entire page code from scratch instead of only those parts that change from page to page which is quite time-consuming (these are 5 to 20 seconds that you can spare).
Mentioning other downsides of the solitary approach, to say the least, it is hard to customize and quite out of date. This doesn’t allow for building sites according to the modern standards and the constantly growing user expectations of today.
That said, monolithic sites greatly differ from modern decoupled ones. In the last five or so years, numerous spheres of the online world have leveraged decoupling the frontend and backend constituents of an application. Now it has made its way to eCommerce. The approach bears the name headless eCommerce.
Wikipedia gives the headless commerce definition and explains the “headless” term using a clear comparison. The frontend of a store is its “head” that gets cut off from the backend “body”.
So, answering the question of what does headless commerce mean, in essence, it revolves around splitting the store’s frontend from the backend. Such decoupling or unchaining provides grounds for creating a flexible architecture. This means that it’s much simpler for you to craft the system according to your business needs and to deliver a better experience for your customers (regardless of the device they use to shop).
We’ll cover how this works in more detail.
Let’s dig a little deeper and try to get to the bottom of what makes headless commerce so different from the solitary approach.
a) Coupled Traditional Commerce Systems
This type of system is often referred to as “legacy” or “monolithic”. Traditional eCommerce stores with such a solitary architecture were tailored mainly for desktop use and can’t adhere to the way online retail runs today.
Coupled is the case when all vital business processes are set up and maintained in a single environment. This leads to an obvious lack of flexibility that forms barriers. As such, monolithic architecture constraints can delay many crucial processes from store development and its updates to the speed of content delivery to the client. At the end of the day, it’s hard to scale such online retail stores and make them technologically modern to suit the growing consumer demands.
Most of the eCommerce stores that were created in the past ten years work the following way:
- There is a backend that’s developed using either a custom framework or based on an out-of-the-box solution, such as Magento or SAP Hybris.
- The backend generates the frontend (HTML) and passes it to the browser.
- The browser parses the HTML and downloads all the required assets (JS, CSS, etc). This procedure happens every single time that a user moves from one page of the store to another which takes time and keeps customers waiting.
Such an approach was more than fine in the 2010s. Currently, this causes many problems. Below we’ll break down the main disadvantages of using the monolithic solution.
1. This approach is usually oriented at just a single desktop channel and is most suitable for browsers. It isn’t capable of tailoring to numerous modern devices that customers prefer to use as they shop online. So, it’s impossible to create a solution that’ll be capable of living up to the expectations of today’s consumers and the quickly evolving world. Meaning that the business is missing a lot of potential traffic and revenue from other devices (smart assistants, tablets, smart TVs, etc) because it is incapable of providing the due UX and UI.
2. The store can cope with desktop browsers well but generally has poor performance on mobile ones. When accessed from a mobile browser, the page load times are slow across the whole store. This happens because the HTML is parsed from scratch with every opened page. This irritates customers, often forcing them to close the page and leave empty-handed.
3. Following from the above, sluggish performance hurts SEO. Even if your store isn’t oriented towards mobile devices and you’re targeting only desktop use, Google takes page speed into serious consideration when ranking a site. Therefore, having such a monolithic store, you may be already losing to your competitors in terms of SEO.
4. It’s impossible to make changes and updates in just the frontend or backend component. Developers are forced to make changes in both, going back and forth. This slows down development time and increases the chance for site breaks since if something goes wrong, both parts of the monolithic system will be hurt.
As you can guess, the non-separated approach that was described above isn’t suitable in the 2020s. The purchasing habits and shopping behaviors have greatly changed.
More and more new channels and devices which people could use for shopping purposes apart from their desktop computers emerged. We’re talking about touchpoints like smartphones, tablets, Amazon Dash Buttons, smart refrigerators, TVs, and other home devices, smart speaker assistants like Alexa, and a plethora of other solutions which allow users to buy things online.
So what is a headless eCommerce solution in particular? Does it all go down to just splitting the website’s frontend from its backend?
Let’s take it one step back and clarify a part of the headless eCommerce definition. It should be made clear that in this case, the “frontend” of a site means not only what users see from their browsers. Instead, the frontend implies requests that can be made from all possible devices that people use to make purchases online. These are mobile apps and tablets, TV sets and fridges, voice assistants and smart speakers, and, importantly, all the devices that will be created in the future.
By decoupling the store, your frontend and your crucial backend business processes don’t affect each other. Your modules become more independent. This includes splitting your backend services too, for example, those that are responsible for voice search and are used in smart speakers can exist apart from the services that deal with the text search used in mobile apps. With this approach, you can advance one part without the risk of harming the rest.
A genuine headless commerce solution is independent, and its autonomous modules can work cohesively with each other. Bottom line, you get the flexibility “ace up your sleeve”.
At this point, you’re probably wondering how is headless commerce architecture built? We’ve put together an infographic that clearly shows how headless commerce works and differs from traditional monolithic systems.
1. On the 4th bottom level there are databases. They keep and organize the online store’s information.
2. On the 3rd level just above them is the backend. The backend is either built with a framework or using a ready-made BaaS (backend-as-a-service) solution. This way, all the vital logic that deals with the store (for instance, business processes such as accepting payments, working with orders and shipping, or managing an inventory) exists separately from the frontend(s).
- Note that in our infographic the backend is split into microservices. These are independent and isolated chunks of code that each work with their own separate database. For instance, there may be individual microservices such as the catalog, search, shopping cart, checkout, payment, CMS, or customer support. By having a divided architecture like this one, you can achieve stability and simple scalability.
- Nevertheless, there also exist cases when headless commerce has a monolithic backend (without the division into microservices). Yet such an approach can’t be considered proper because headless implies that different services use various frontends. Therefore, they should be isolated from each other as much as possible. In this scenario, when you update one microservice, it’s quite unlikely that it will affect other microservices or create issues.
3. All of this combined forms a backend that’s called headless commerce which we see on the 2nd level. The backend provides data for the first level (the “heads”) with the use of API in different formats such as JSON, GraphQL, etc. No matter which platform is on the receiving end, it’ll get content through its corresponding API.
4. At the very top 1st level we have various “heads”. The headless commerce front end mainly deals with the presentation and is responsible for interacting with customers. It is created independently for different device types. Basically, this means that the store can have multiple “heads” attached to one backend if your business has different touchpoints and channels of contact with your customers.
To compare, on the right side of the infographic you can see how monolithic traditional commerce works. As you might have guessed, adding and supporting new devices can be problematic with such an approach.
3. Approaches to Building Headless Commerce Backends & Frontends
Now let’s go over the possible ways that headless commerce frontends and backends can be built in more detail.
As we’ve noted previously, in the headless commerce approach, the backend serves as a solution that fits all devices. Depending on the business type or site that you have, there are several backend creation paths that you can take.
1. If you have a custom solution
Let’s assume that you have a large-scale eCommerce business with your own platform that you’ve been developing for about a decade. For such companies, switching over to headless commerce is a path towards advancement and the future.
In order to make the switch, your custom platform needs to obtain a microservice architecture on which the headless will be based. It doesn’t matter which coding language is used for your store. To make it headless, you’ll have to decouple the store’s layers and place each of them in docker containers.
Without a doubt, this is a difficult and complex process. And for a large enterprise, building headless commerce this way makes sense only if your store is super-customized and has many unique solutions developed specifically for your business. Also, you can take this path if moving to a solution like Magento will be ineffective for you. Luckily, you can gradually rework your site chunk by chunk without stopping vital processes.
2. Using a 3rd party platform with accessible/changeable code
There are numerous platforms that serve as a basis for eCommerce stores. Here we’ll cover those that allow making changes in the source code in the backend.
As of today, Magento headless architecture doesn’t support “true” headless commerce since it doesn’t have a microservice division. Nonetheless, it supports GraphQL API and allows splitting the backend from the frontend. To say the least, it is possible to develop Magento progressive web applications or to link up any frontend. The only difference between this eCommerce headless CMS from genuine headless commerce is that there is no microservice architecture for Magento yet. But it’s very likely that there’ll be an Adobe headless commerce solution for Magento sometime soon.
The next open-source eCommerce platform is Sylius. Based on a Symfony framework that’s very scalable, the solution is made from independent components and separate PHP libraries for various parts that make up a shopping process. This headless eCommerce framework allows for creating microservice apps. Based on the official documentation, Sylius claims to support numerous tools that are required for building a microservice architecture.
Pimcore is also an open-source eCommerce framework based on Symphony. Its REST API can be used to create a backend solution for an eCommerce store or mobile apps or as an extension to the current capabilities of the eCommerce platform. According to the information on their official website, the solution offers headless and API-focused content delivery.
Mentioning other eCommerce software that’s open-source, Shopware 6 has a major focus on API. The technology is backed by VueJS and Symphony and is noted for its flexibility. It gives the opportunity to split content. As stated on their site, it has a focus on the API-first approach.
3. Using a template-based SaaS platform that’s currently taking steps towards headless adaptation
Now let’s move on to those software-as-a-service platforms for creating eCommerce stores that are more template-based and don’t allow us to change the backend source code.
Despite its popularity, Shopify isn’t currently “ready” for headless commerce. There is some API available, yet it does not allow you to customize everything, for instance, the account and checkout. On a similar note, it isn’t clear whether the division into microservice architecture is possible or not. This may change in the future, though. There’s a big possibility that after some time Shopify will offer headless commerce software that might suit your specific business needs more. So, if you’re happy with Shopify, you can postpone your headless commerce “shift” and be on the lookout for updates.
BigCommerce is also among those headless eCommerce platforms that support out-of-the-box backend solutions for headless purposes. It uses the API-driven approach that can help large enterprises smoothly transition to headless that’ll serve numerous endpoints. As mentioned on the official site, BigCommerce allows for creating various shopping experiences based on a powerful commerce engine.
Salesforce Commerce Cloud
Previously called Demandware, the popular Salesforce Commerce Cloud is also commonly used as an eCommerce solution. Its Salesforce Commerce API is a RESTful API that allows for headless development and building storefronts. It is fitted with improved capabilities, including the API gateway that can support multiple tenants, an eCDN layer, among other features. In reality, RESTful API is not as convenient as GraphQL, but we think that after some time Salesforce Commerce Cloud will be fitted with GraphQL too.
SAP Commerce Cloud
Also commonly referred to as SAP Hybris, SAP Commerce Cloud is founded on open APIs. According to official data, it can be simply integrated and offers omnichannel eCommerce solutions. These include expanding to numerous touchpoints via the headless approach. Plus, in order to extend the platform, it offers the serverless microservices path.
4. Using a BaaS solution
The fourth path you may consider is investing in “backend-as-a-service” for your headless commerce backend. BaaS presupposes that after making the payment (be it on a subscription basis or not), you get access to the API which you can use to build your backend. However, you can’t change the source code of the backend (for example, this is similar to the case that you can’t upload Apex in Salesforce). This is only an emerging trend, and so it’s no surprise that on the sites listed below we did not find any examples of stores made with the use of this or that particular BaaS.
The headless commerce BaaS solution provided by Fabric offers APIs for headless commerce stores as well as backend solutions for decoupled frontends. As indicated on their official website, their suite has powerful APIs and supports microservices architecture.
Similarly, Elastic Path also has a lot to offer modern eCommerce stores in terms of headless commerce. In fact, based on their website, the company provides microservices-based backend architecture and an enhanced toolset for flexible integration.
Based on the information presented on the official Commerce Layer website, this BaaS is initially designed for headless commerce. Alongside secure API it offers an OMS (order management system). This makes creating scalable, multi-channel, and fast online stores and channels of sales that’ll suit clients at various touchpoints.
The following headless commerce platform, commercetools, is cloud-native. It encompasses various backend processes and offers over 300 flexible API endpoints. In accordance with the information on their website, they support microservices architecture and have pre-built solutions called “Accelerator” projects that allow businesses to get started with the headless transition very quickly.
Bold Commerce also provides headless API-driven solutions for eCommerce businesses. Transaction experiences are its main focus. As mentioned in the official documentation on their website, there are API solutions for products, checkout orders, price rules, subscriptions, product recommendations, among others.
Everything is much simpler with frontend creation for headless commerce. As shortly aforementioned, the frontend is crafted separately for various devices. It is developed using modern technology that’s capable of working with API and allows you to implement what you need for each specific platform in the shortest possible time. Let’s go over a couple of main ones.
1. For regular browsers, the frontend is usually built using a progressive framework. Such frameworks, for instance, are VueJS, ReactJS, or AngularJS.
3. Mentioning smart speakers, the frontend of the Google Assistant is created with the use of Dialogflow (a platform that’s needed to process natural language) and with Actions on Google. What’s for other smart speakers, each has its own development platform.
To conclude the above, there are many reasons why headless eCommerce is an advantageous move. Let’s go over the main points why the innovative approach is gaining popularity and why you should consider headless commerce for your business.
a) Broader Customer Reach & Better User Interaction
The expanded multi-platform opportunities and multi-channel capabilities of headless commerce can enable your store to process requests made from various devices. Because the approach allows having multiple “heads” and touchpoints with the user, this is a way to create an omnichannel solution. Those devices that’ll emerge in the future aren’t a limit, so you can think ahead businesswise.
More endpoints for interacting with the audience also mean broader audience reach. Furthermore, the solution can support various localizations, languages, and region-specific shipping and payment matters, among other things. All of this improves user interaction since customers aren’t restrained by using just their desktop computer or mobile browser.
b) No Customization & UX/UI Boundaries
For headless commerce, there are practically no limits with design or idea feasibility. Even if you want something very advanced. Because there is no “fixed” and predetermined frontend layout, developers can control what the headless storefront will be like for any sales channel or device the client uses and which features it’ll have.
This means that you have the freedom to craft your own UX\UI for each individual device and touchpoint, thus providing an enhanced user experience. With no design constraints, you get an adaptable and flexible store that can easily and quickly be changed together with the market and user expectations.
Plus, this way you can have your frontend adapt to the times without the need to change any vital backend processes.
c) Faster Development & Implementation of Changes
The reduced time that’s needed for development works when applying the headless approach is another benefit. Fewer hours are spent on development since the additional frontend/backend modification step is skipped. Altogether this shortens downtime, boosts efficiency, and can omit multiple bottlenecks. This gives developers the agility that they need, all resulting in a quicker time-to-market.
There’s no need to mention that this saves your business money, time, and gives a competitive advantage over other less progressive online retail stores. You can make changes faster, thus, your store can be equipped with upgraded features in shorter periods of time.
d) Smaller Chance for Breaks after Updates
An unquestionable advantage of headless commerce is that you stop worrying that something will break in the backend when you make frontend updates (or vice versa). They exist separately, therefore, don’t affect each other during deploys, releases, or updates.
For example, with headless, if you make updates in one microservice, there’s a very small chance that it’ll do damage to your other microservices or create some problems. Microservices aren’t interdependent, so their possible negative effect on each other is unlikely.
On another note, the headless approach is also considered to be very secure. It is much simpler to control the matter of authorization and data access for different users.
e) It Boosts Speed & Conversions
Importantly, the headless commerce approach allows for achieving fast content delivery speed. Due to the fact that required content is pulled using API calls, it can be delivered faster.
In the case of websites, rendering is also much quicker. Unlike with the monolithic approach, when a user browses a headless website and moves from page to page, the displayed content isn’t rendered entirely. Specifically, unchangeable content that is the same across the whole site (such as the one in the footer area) doesn’t have to be rendered over and over again. In this scenario, only the content that’s distinct on every page is rendered, and this greatly improves speed.
Not to mention that site visitors are ultimately happier when the pages load on the fly. This reduces bounce rates, enhances conversions (including mobile ones), and simply improves the overall shopping experience. This is good for the site’s performance which positively influences SEO.
f) Headless Commerce Is Used to Build PWAs
Prior to jumping over to creating headless solutions for new devices (like smart TVs or others that aren’t used as often to shop in your store today), most online retailers should modernize and improve their store’s desktop and mobile versions. This is a reasonable first step.
Headless commerce technology can be used to develop progressive web applications. When opting for a PWA, you’ll transform the architecture of your backend to work with APIs. By doing so, you’ll pave the way to linking up new touchpoints to your store later on in the future.
PWAs are also a great alternative to native applications, boasting superb speed and UX/UI. Significantly, they work right in the browser, meaning that the user doesn’t need to install a heavy-weight downloadable app from Google Play or AppStore directly to the storage of their device. If required, the user can add the PWA’s shortcut to their home screen in the form of a link that’ll look like any other application yet weigh practically nothing and launch in the browser when clicked.
When building Magento PWAs, you can count on having a responsive design. The “look” of the progressive app is very reminiscent of a native application. All elements are conveniently placed, making shopping from a mobile device a blast.
The progressive app can be used in offline mode and is capable of supporting push notifications. In addition, due to the use of GraphQL and modern frameworks like ReactJS, the PWA’s pages load with lightning speed, making both the site visitors and Google bots ultimately happier.
Of course, this all leads to the enhancement of conversions, especially mobile ones. There are already many outstanding headless commerce examples of PWAs you can browse, as numerous renowned brands and large players on the market are happily reaping the fruits of this technology.
Ok, to be fair, headless commerce solutions aren’t all perfect. Bringing up the drawbacks, shifting to headless is not a quick process that’ll require both time and money.
If your online store is complex and currently based on a large-scale traditional commerce system and you’ve decided to go headless, the transition may get tricky. Mostly due to the constraints of the monolithic architecture. You’ll need an explicit and detailed plan in order to not extend the project’s timeline. In any case, the “reconstruction” can be handled one piece at a time, allowing you to “move” gradually. Additionally, you may consider going for pre-built integrations and ready third-party solutions to speed things up.
In Which Cases Is Headless Commerce Not the Best Solution for Your Business?
To some extent, it depends on what you mean by “headless”. For instance, you may imply the complete and complex microservices architecture that allows you to work with a bunch of devices.
If you have a small online retail business, and the majority of your customers buy things in your store using certain devices, then you do not need headless. In this case, you can choose in favor of getting a progressive web application that’ll help you enhance your store and get a hold of more orders made from mobile devices (check out these PWA examples for some inspiration). This will be a smart first step towards headless.
Assuming that your eCommerce business is large, it’s possible that you might be tempted by the idea to postpone such a transition to headless due to lack of resources, be it time, budget, or anything else. Yet in reality, if your business is competing for a large share of the market and wants to take hold of as many customers as possible, switching to headless is the only path that’ll allow you to remain competitive in the long run. But, again, you can start small.
Everything you’ve learned in this article describes the future of eCommerce in the next 5 to 10 years. As of today, it isn’t necessary to dive into digital modernization completely and go very far beyond traditional browser shopping. This means that supporting the full spectrum of possible sales channels and devices doesn’t have to be your top priority at the moment. Especially if you have a small eCommerce store.
Regardless of the size of your eCommerce business, your main goal right now is to get the maximum of your store’s desktop and mobile versions. In addition, you can do some preparation work in terms of evolutionizing your architecture so that you can add on new touchpoints when you need them later on.
You can begin by getting a progressive web application that’ll help to optimize your store for desktop and mobile devices. The process implies a transformation of the backend to communicate via APIs. This will prepare the groundwork for your architecture to support new sources of sales after some time and can become a competitive advantage for you now and in the future.