WRITTEN BY TERO JUNTTILA, CTO & CO-FOUNDER, WOOLMAN
New Commerce Insights Podcast Episode: The Future of CAC Reduction: AI-Driven Asset Management Techniques for D2C Brands Listen here.
Headless commerce has been one of the buzzwords in eCommerce lately but it has been around nearly a decade. What is this fuss all about and where does it come from?
Technical eCommerce architecture approaches have evolved a lot since monolithic architecture back in the mid 2000s that was designed for desktop and tightly coupled with back-end components and even with technical infrastructure. Mid-2000s might sound ancient but still many merchants are relying on this setup. After a couple of different architecture attempts to combine commerce and content functionality together we have come all the way to the true API first approach that ties together all the back-end logic and data, and businesses should finally be able to get the best of both worlds. The idea is not new but now the change has also been driven more and more by the rise of the API economy.
Without going deeper into different architecture approaches along the way, we can simplify the change by dividing the timeline in 2 periods; before mobile and beyond desktop. Since the launch of the first iPhone, online sales have evolved a lot. Consumers are now spending a great amount of time with their different devices and they are using them all to shop through different channels. You could call that multi-channel or omni channel – dear child has many names – but let’s just call it commerce as it is today. During last years’ fast growing D2C trend and since March 2020 Covid-19 eCommerce boom the record level competition is also raising the bar on how brands are engaging with consumers.
The beyond desktop era has significantly increased the demand for merchants to meet their customers in multiple touch points and sales channels. Not just desktop and mobile but also other online channels like social, voice, messages, apps etc. and even in-stores. The winner is who utilises the data best to understand the customer and builds the most appealing brand with a great and seamless customer experience in all channels and for all devices. Headless Commerce architecture was invented to answer these demands without building every channel or device experience from ground up.
Headless Commerce refers to a technical architecture which is decoupling a website's presentation layer – the front-end – from its commerce and business logic layer – the back-end – using API layer. The architecture exposes all back-end functionalities and data through APIs and enables developers to build flexible UIs for all customer touch points and utilize their front-end technology of choice.
Just to make terminology clear, headless does not mean your commerce solution doesn’t have a “head”. While traditional commerce architectures have a standard website that customers visit and it acts as the single “head.” The tightly-coupled “body” underneath contains the eCommerce logic, data and processes. With headless commerce the “body” remains but it also provides a set of services (APIs) that allows you to select the type of “head” you want.
Wow! Does that solve all my problems then? Is it the silver bullet? Oh well, it comes with many advantages but let’s dive a bit deeper than the history and the definition. How does headless commerce help with that? Basically, it tries to solve 2 major problems:
Because everything is decoupled you have (at least in theory) freedom to choose the back-end and front-end components and technologies that are most suitable for your needs. With headless approach businesses can then change and scale customer-facing experiences across multiple touchpoints without disrupting the functionality on the back-end.
But with great freedom comes great responsibility. While modern and SaaS based eCommerce platforms have been simplifying many technical aspects of commerce, headless commerce is putting technology stack back on the table. Headless commerce architecture certainly has its elegance and reusability but these are not synonyms for simplicity and low costs.
Luckily there is a selection of eCommerce platforms that can power the back-end and at the same time give you the freedom to build a unique customer experience with modern front-end tools. Some platforms are fully based on headless architecture and some are supporting it with a special set of headless APIs.
The back-end layer of headless commerce architecture can be constructed from building blocks a bit like Legos. For example key components can be an eCommerce platform, Headless CMS (Content Management System) and set of additional platforms and services like CRM, recommendations engine, search engine, loyalty system, ratings & reviews, etc.
To speed up things you can select so-called ecosystem apps into your architecture that are already integrated on the back-end level to exchange data – so your data would not be completely in silos in different back-end components. But make sure that all the apps you select are providing needed headless APIs so you can build the type of “head” you want.
The front-end layer with headless commerce architecture is very flexible to design and build on but it can also be a bit more tricky because it is always more or less custom built. There are good tech stack frameworks to follow and also some front-end platforms available but no more ready made and fully functional templates that modern SaaS platforms can offer today.
APIs are application programming interfaces that allow developers to glue the front-end features together with the back-end logic and data. APIs are traditionally used in back-end integrations such as order data or inventory information integrations between back-end systems. These APIs have been anything from XML or CSV file transfers to more modern REST APIs etc.
Requirements for headless APIs are totally different. Headless APIs have to be much more flexible and often high performing when connected directly to customer facing front-end applications. And most importantly headless APIs are not designed to just transfer data to connect back-end processes but to expose the back-end functionality for the front-end. While traditional integration APIs were running sometimes only once a day and processing large amounts of data taking sometimes several minutes, headless APIs have to be able to perform smaller real-time actions often in a matter of milliseconds.
Another important thing is the API coverage. Commerce platform used to power headless commerce needs to be built with an API-first approach. It means that all or at least most of the functionalities are exposed via API.
New types of APIs – like GraphQL, are useful with headless commerce. GraphQL is a query language for APIs and a runtime for fulfilling those queries with your existing data. GraphQL provides a complete and understandable description of the data in your API, gives clients the power to ask for multiple resources at once and exactly what they need and nothing more, which makes it easier to evolve APIs over time, and also enables powerful developer tools.
Okay, let’s turn these technical nuts and bolts into business benefits. What can you expect and what are the common use cases?
While this article is mostly explaining the big picture of headless commerce, some common use cases can be found from more specific business needs with one or two customer touch points.
Because you are able to choose the type of “head” you want, you are also able to use the best and most modern front-end technologies to design and build the best possible experience out there for your customers. Headless can also enable to utilize more native features of different devices like cameras etc.
A headless approach allows you to get the best out of content management by seamlessly connecting commerce and content functionality. So you are able to fully utilize a headless content management platform with all its features with your shopping experience especially when you are dealing with a large amount of personalized content.
Do you need a mobile app? PWA (Progressive Web App) implementation might be a cost effective alternative to Mobile SDKs. Or do you want to sell you products within a video game? Then headless and API-driven architecture gives you the tools to build your storefront inside the game.
Studies show that fast loading times are important for conversion rates. Google has also started to use loading times as criteria for their mobile search results and Google has confirmed that Core Web Vitals (Loading (LCP), Interactivity (FID) and Visual stability (CLS)) are becoming ranking signals for search results in May 2021. Facebook is also prompting slow loading times while opening content with its in-app browser. If the high performance that modern SaaS platforms can offer is not enough, headless architecture gives you the tools (PWA = Progressive Web App with partly static content) to achieve extremely fast loading times when built correctly.
But if you are planning to solve overall platform scalability with headless front-end implementation, you might be solving a right problem with a wrong tool.
Headless commerce is not only supporting multiple customer touch points but also connecting different logical back-end components under one storefront. For example selling merchandise with one commerce platform, ticket or digital assets with another and managing content with 3rd platform etc.
This is often stated with headless architecture but it might not be exactly true but quite the opposite. Using standard implementation models that modern SaaS platforms are able to offer are most likely faster to develop and update than headless implementations. But headless gives you also fast deployment options and the development is usually faster than with traditional or legacy eCommerce platforms.
First of all Shopify Plus is a great example of a platform that can power the headless commerce back-end and it also provides an API to support headless implementations called Storefront API. It also has the largest ecosystem of additional technologies to choose from that are usually pre-integrated on the back-end level which is a very essential advantage. Shopify also has the critical mass that makes it an interesting partner for all headless platforms and frameworks to connect. But is the headless commerce right fit for your company is still a good and very relevant question.
Question: The platform is already supporting all the touch points and sales channels I need for now. Should I still adopt headless commerce?
Answer: Headless commerce architecture is not adding any value itself if the touch points and sales channels are already simple to develop and maintain. Shopify is already separating business logic from front end quite effectively. For example logic in liquid templates (themes) can be modified separately from business logic that is customized with public or custom apps and communication with Shopify via APIs. My advice is to consider the benefits you would like to achieve with headless commerce.
Question: Can I utilize the Shopify ecosystem and apps like I’m used to?
Answer: Back-end app yes but with front-end apps you cannot anymore follow a simple installation process. You need to implement the app into your front-end solution using APIs apps are providing or build the functionality from scratch if there are no APIs provided by the app.
Question: Are all apps supporting headless commerce?
Answer: No, most of them are not. Bigger ones are starting to support it but you need to check it one by one.
Question: Does headless commerce save cost or time?
Answer: Most likely not but quite the opposite. Headless is adding an extra layer of complexity and need for understanding of overall technical solutions compared with traditional Shopify implementations.
Question: Do I need to build technical competence within my own team?
Answer: Well, you might outsource it to your Shopify agency partner but developing your business further and understanding your own setup it might be a good thing to have it at least on an architecture level. Also every headless implementation varies from each other much more than traditional implementations so might end up in a vendor lock with your partner.
WRITTEN BY TERO JUNTTILA, CTO & CO-FOUNDER, WOOLMAN