Blog

Headless Commerce Using Shopify Plus

March 15, 2023

Headless is the buzzword of the moment, and there’s a lot to unpack with this exciting development in e-commerce. In this article, we talk about what it is and how to do it right.

What is Headless commerce?

An e-commerce website is made up of the part a customer sees (the “front-end” or “head”) and what the business uses to manage the website (the “back-end”). More often than not, both the front-end and the back-end are powered by the same system, such as Shopify. This is called a ‘monolithic’ architecture and has been best practice for the last 20 years, for many good reasons.

Monolithic architectures make the day-to-day running of things easier, but also mean using a single system for multiple purposes, rather than a single-purpose system for each business need. This is normally an advantage; having one system makes everything simpler to run. But, sometimes, you need more flexibility on the front-end that’s not catered for by the back-end system.

To meet this, you need to use two or more systems that are optimized for each function — and have information passed between these systems via an Application Programming Interface (API). This concept is known as a ‘Headless architecture’ because the back-end (normally an e-commerce platform) has no ‘head’ i.e. no user interface, but instead communicates with the front-end via APIs. APIs are how computer systems ‘speak’ to one another by requesting and passing data.

Headless commerce platforms (i.e. those that have an API interface) are sometimes called 'commerce-as-a-service'. An example would be Shopify or Magento with a Headless configuration. Equally, API-first content management systems are sometimes called 'content-as-a-service' too, with examples being Contentful, Prismic and maybe even Adobe Experience Manager.

Headless is a term that is immensely popular and almost pointlessly broad. It's come to capture a shift away from monolithic platforms and is slowly making its way into the e-commerce mainstream. But watch this space, because we believe it's about to speed up.

Headless in one sentence

The decoupling of the front-end and back-end of an application, with each powered by different technologies and interconnected via a series of APIs, allowing for the total optimization of each system for its specific purpose.

Reasons to consider headless

Headless websites offer huge opportunities for blending experiences using multiple data sources and also offer real speed advantages over the traditional, monolithic approach. They bring incredible flexibility in terms of design and functionality to the user, including app-like experiences through the use of PWA technologies. And while initial development costs can be higher, continuous integration and modular design mean ongoing development is quicker and more flexible with a headless build.

Do note, however, that migrating your website to a headless architecture can be expensive. Depending on the systems you use, you are building and structuring your flow of data from the back-end to the front-end from scratch whilst introducing and maintaining multiple systems.

If you want to go down the route of Headless commerce, the pros need to outweigh the cost, time and effort. Headless isn’t right for everyone; we wrote this guide to help you decide if it’s right for you.

You want to use an external CMS

One of the exciting benefits of a Headless architecture is that you can combine two back-end systems and get the best out of both. For example, you could use an API-first CMS like Contentful that will offer you more complex content models, and combine this with the power of Shopify’s e-commerce catalog CMS. The front end of your website will combine these together into a seamless experience.

Information architecture flexibility

One of the constraints of a monolithic e-commerce SaaS platform like Shopify is that there’s limited flexibility around URL structures and Information Architecture. For example, product detail pages live at /products/product-handle whilst product listing pages live at /collections/collection-handle, and so on.

From an SEO perspective, this is a proven, effective structure, but there are times that a merchant might wish to deviate from this rigid formula. A Headless architecture unlocks limitless possibilities in these instances.

Take, for example, a multi-brand marketplace: it may be beneficial for both SEO and branding purposes to offer tailored experiences at brand-specific URLs. This point is particularly important for brands that are replatforming from other platforms that don’t share Shopify’s URL structure — with a headless front-end, they can keep their current URL structure and avoid a risky SEO migration.

More design freedom

This is usually the biggest reason given by merchants wanting to explore Headless. It’s true: headless does afford more flexibility when designing your customer experience — just as building your own house grants you flexibility. You have free reign, but at a hefty cost and undertaking.

It's also important to note that design constraints aren’t necessarily a bad thing. In fact, they’re needed if you wish to benefit from systems that have been built over many years to be best-in-class. Shopify’s a great example of this. There are some limitations, but these are few and far between and don’t affect 80% of businesses. And when they do? A Shopify Partner like us can likely help you out (read our article on workarounds for Shopify’s design restrictions).

With that said, you can build exceptional experiences with a Headless architecture. The front-end can be built in a lightweight, modern front-end framework and from the ground-up for your exact use cases. Here are some of our hand-picked examples:

nomad
Nomad's front-end with headless back-end functionality
kitsch
Kitsch's clean and minimal front-end design
groove
Groove's horizontal display front-end

Sub-second page load

Headless websites give us the ability to create storefronts with sub-second load times, even on mobile. Metrics like load speed, perceived load speed, and time to interactive, are among the highest factors affecting bounce rate, so improving them is going to improve your business.

We live in a mobile-first world now where networks are normally slower than in home or office, but our expectations of speed are not. Google is also paying more attention to speed, the recent changes to Google search rankings to include Core Web Vitals is a signal to everyone that speed is a real factor in both users' perception of quality and trust. Achieving a ‘passing’ score in Core Web Vitals on mobile devices is frankly no mean feat, and for many existing themes, the remedial work required is significant. Headless is one way in which the problem of speed can be tackled directly, and can result in real ROI, especially when considering the other potential UX benefits.

This is possible because modern javascript frameworks use data only page transitions and caching to keep computational and transfer requirements to a minimum. Until recently these frameworks were simply less compatible with monolithic systems.

While the practice is still very new to Shopify, the platform itself is embracing it. The paired Oxygen server and Hydrogen theme (now under development by Shopify) are the official way in which merchants can — without any third parties — build Headlessly. These developments are still a year or so away from production, but the path is already laid clear: Headless can bring meaningful results.

Spinning up new stores is easier

Headless architectures can make it easier to add expansion stores, such as when you’re adding new international regions. If you have a lot of data re-use on the back end (product catalogue, content, rest of tech stack) but want to be able to charge different prices and show different languages, you can have front-ends configured for each.

You want to expand your digital touchpoints

Customers expect to interact digitally with your business, and that used to just mean you needed a website. Now, there are many other digital touchpoints to consider: Progressive Web Apps (PWAs), mobile apps, marketplaces, billboards, POS, voice search and so on. Having the content, catalog and business logic re-used across all these touchpoints makes sense, which has led to the rise of ‘Headless’ platforms for both commerce (product catalog, order management and so on) and content (managing content that should be replicated across all platforms).

You need a PWA

Progressive Web Applications (PWAs) are another big trend and are difficult to achieve using a Shopify theme.

A PWA is a way of providing native app-like features through your website, without the user having to find and download an app through the Google Play or Apple store.  Instead, the website in the browser asks the visitor if they want to download the website as an app —which happens near enough instantly. You get some native app-like features without the expense and overhead of building your own native app for each device operating system. With a PWA, your website:

  • Works offline, for the most part, after the initial load using Service Workers.
  • Can be added as an ‘app’ icon on a smartphone home screen with a customizable splash screen.
  • Is extremely fast as most content is pre-loaded.
  • Can trigger native push notifications, which can be used for marketing purposes.

PWAs rely on traditional web technology such as HTML and CSS to power the styling of content but also rely heavily on JavaScript to power the content delivery and offline interactivity. We use Nuxt.js for the website front-end, which includes an out-of-the-box PWA implementation that uses Node.js and Vue.js as dependencies. There’s a lot more to be said on this, but not in this article.

Custom architectures

Every business has its own needs and often they are embodied by a custom tech stack, where systems are never configured or interacting consistently. But for businesses that require a little more customisation when it comes to architecture, headless can be a good way of moving to a more service-oriented approach.

Reasons to avoid Headless

You want to keep project costs low. With all the extra workshopping, development and complexity, you’ll be dealing with a much larger project.

You don’t want a high ongoing cost of ownership. You'll be maintaining a codebase that requires a deep skill set, therefore you will need agency help or a developer with experience in Node.js and React/Vue as well as the Shopify ecosystem.

You want to utilize the Shopify app ecosystem. With Headless, you will be able to integrate apps into Shopify, but will need a custom approach based on unique requirements. There is no such thing as a "plug-and-play" install. The apps will also need to have APIs for all the features you want to use.

You and your team like the theme editor in Shopify. You will no longer be able to use the WYSIWYG editing, versioning and previewing features within Shopify. Instead, you’ll be changing content on your content platform and previewing through a sandbox version of your website. However, this functionality does exists in some front-end-as-a-service tools like Shogun Front End and Builder.io.

You want to upgrade your platform with new technologies every few years. Shopify Plus is always rolling out new features, such as multi-currency. These will not be available to you unless you build them into your front-end at a further cost. This also includes all the other tech components in your architecture like Nosto, Yotpo, and other front-end marketing solutions.

Traditional vs Headless architecture

Traditional e-commerce architecture

non headless

What the customer sees (the “front-end”) and what the business sees (the “back-end”) are often part of the same system, such as Shopify. Content management (the updating of pages and products), and commerce management (the updating of orders), all happen in the same system.

Bigger companies have the option to use an ERP (Enterprise Resource Planning) system as a single source of truth across the organization which helps with operations such as purchasing. The website connects via API integration with the back-office layer.

Example of a Headless e-commerce architecture

headless

In the brave new world of headless, the multiple ways in which a customer interacts with your business sit together on what we call the ‘Customer Experience Layer’ aka the CX Layer.

Content management and commerce management happen in specialist systems within the Service Layer.

Then, for the bigger businesses, the CX and Service Layers integrate into the Back Office Layer. Usually, this is an ERP system that is used for inventory management, CRM, purchasing, finance and production.

CX layer

Website - the ‘front-end’ aspect of the build consisting of all the HTML, CSS and JavaScript along with any frameworks used for generating complex interactive functionality. These might include frameworks like Hydrogen, Next.js (React) or Nuxt.js (Vue.js) to scaffold a modern web application.

PWA - Progressive Web App, a type of superfast mobile-first application delivered through a website using traditional web technology. This is an alternative to a standalone app you would typically install from the App Store.

Native mobile app - any native iOS / Android apps you have.

POS - Point of Sale, so any in-store systems used for handling customer orders.

Voice commerce - a nascent example of new touchpoints customers might have with your business. Headless architectures allow you to build new touchpoints separately to the content and business logic present in the service layer.

You may have many other digital touchpoints. Amazon and other marketplaces you sell through would also sit on the CX layer. Your commerce platform then connects to each, so you can enjoy one place to maintain your product catalog despite selling through multiple channels.

Service layer

CMS - Content Management System, in this case, a Headless one (also known as a content platform or content-as-a-service). This is where content such as pages, navigation, store settings, blog posts and API permissions are defined. It is also where the content is added, edited and removed. The content can be pulled through to each touchpoint on the CX Layer, for example: a returns policy page on the website could share the same copy as the POS receipt and the iOS app.

E-commerce platform - Shopify, Magento and Salesforce Commerce Cloud are all examples of e-commerce platforms that support Headless. Customers, orders and products are managed within the platform and, in some cases, it’s where payments are processed. Shopify’s native checkout can be used even in a Headless architecture.

Back-office Layer

ERP - Enterprise Resource Planning. The main component of the back-office layer is an ERP like Netsuite or SAP. It is a ‘source of truth’ for things like inventory levels, locations, customer data, purchasing and finance. Smaller businesses may use their e-commerce platform as a lightweight back office.

Shopify as a Headless architecture

No more Shopify theme editor

With Headless, you are foregoing the simplicity of the native Shopify theme editor, and you should know the implications of this:

  • No WYSIWYG editing unless you use a front-end product like Shogun Front End or Builder.
  • No theme previewing.
  • You’ll need to build default pages like customer account pages that are normally out-of-the-box in Shopify.
  • No access to navigation link lists.
  • No ‘sections’ functionality, unless you build it into your front-end.
  • No version control via different themes (although you could achieve this with multiple instances of your headless front-end).

No more one-click apps

If you’re using Shopify, you’re used to quickly installing Shopify Apps to add new features to your store. With Headless, you will need to connect services like Nosto, Klevu and Yotpo directly to your front-end by building integrations to their APIs. This is a considerable task and relies on the services you’re using presenting their own high-quality API.

Update: enhanced checkout protection

In a previous version of this article, we commented on how some enhanced checkout protection is not available for Headless front-ends, including Shopify’s powerful features for brands that do drops and other high volume sales, especially where purchases need to be limited to one per customer.

Thankfully, these cart features are now available to Headless merchants, through the Checkout (bot detection) and queuing APIs.

  • Bot detection: Shopify can detect bots and block them from purchasing.
  • Checkout queuing: Shopify checkout has an immense capacity (roughly 5000 checkouts per minute, or 80 per second, per store). If you expect spikes in sales beyond this, you’ll have access to a queuing system at checkout.

How to go Headless on Shopify

There are four approaches to building ‘the head’, all of which use Shopify’s ‘Storefront API’, which allows you to access commerce objects and create cart/checkout events.

Option 1: using Shopify Hydrogen & Oxygen

At Unite 2021, it was announced that Shopify will allow developers to build React front-ends on their own React server components. React Server Components are rendered in the server-side to improve the performance of React apps. These ‘commerce’ components include the common sections you’d see on a Shopify store like the cart and product order form.

Hydrogen front-ends can be hosted on Shopify’s servers via Oxygen, a V8 worker runtime. This means no dev ops and super-fast load times.

It’s a good solution between the two routes above but hasn’t been tested broadly in the wild yet.

Option 2: building on a framework

We talked about Headless being the equivalent of building your own house. It requires a lot more thought, experience, planning and a considerable amount of back-end and client-side knowledge of Shopify’s API, than going with a conventional architecture.

Building a custom front-end brings great flexibility, but it does mean rebuilding functionality you’d expect to be out-of-the-box in a normal e-commerce setup using Shopify APIs. You’ll also have to build a custom and tested implementation for storing the contents of the cart and then passing them safely to the Shopify checkout.

There are many other examples, where your website will require complex custom integrations which you normally wouldn’t need with a traditional e-commerce architecture. The extreme control you get from the front-end does bring benefits, but it’s down to your overall e-commerce strategy as to whether it’s worth it.

You should definitely consider using a front-end framework with an e-commerce specialism like Next.js​​ or Vue Storefront. With Vue Storefront, you also have the option of hosting your site on their “Storefront Cloud” service.

Option 3: building on front-end middleware

However, with all that said, Nacelle, is an API-first commerce middleware that abstracts away e-commerce platforms, CMSes and microservices into a single API, to speed up development and simplify Headless builds.

It sits between Shopify and your website front-end, bringing all the APIs together that you might use on a Headless project.

Option 4: using front-end as a service

There are many interesting, new products that have sprung up to make it easier to build best practice Shopify.

Examples include Shogun Front End and Builder, which are PWA-builders that include pre-built connectors to popular e-commerce platforms (like Shopify) and services (like search, reviews and merchandising tools). They also include a lightweight CMS plus a visual composer.

Should you go Headless?

There’s a lot of buzz around Headless right now, which is not helped by the number of e-commerce agencies pushing it as a solution to everything. Headless is appealing to System Integrators and agencies because a) it’s fun to do new things and b) the systems are extremely expensive to build, so great for revenue.

If you’re a brand with the means and needs to go Headless, it can be a good way of rationalizing platforms and optimizing known customer and operational pain-points. As a rule of thumb, however, a brand needs to be doing $10m online before going down this route, not least because a Headless enterprise-level e-commerce project is going to come in at $100-500k.

We’re not saying that you need to go Headless once you go past this GMV/revenue threshold; there are brands that do billion-dollar revenues on Shopify themes. All we’re saying is that you need to be in this category to get the ROI on a headless build.

Making a success of Headless commerce with Shopify

If this article’s helped cement that this architecture choice is definitely right for you, here’s how to make a success of your Headless project:

  • Firstly, define ‘done’: what does a successful project look like?
  • Workshop the user journey, for both your customers and your own e-commerce team, involve as many of your stakeholders as possible.
  • Decide on the systems to integrate and the languages/frameworks to use.
  • Create QA/UAT/load/pen-testing plans, ensure all areas of the solution are fully scoped with user stories and acceptance criteria.
  • Ensure you have the necessary access to resources such as professional services contacts, development resources and developer documentation for all systems and APIs.
  • Ensure that all internal business stakeholders such as finance/marketing/content teams have confirmed their needs are met before you build anything.
  • Ensure you have a dedicated team and a clearly assigned project leader.
  • Headless projects are likely to include many suppliers, so choose your team management and communication tools carefully. Consider software such as Asana or Jira.
  • The same goes for stakeholders: any e-commerce project touches many parts of your business so pay special attention to communication.

Of course, if you’re wanting more info on Headless, or are looking for an agency partner to deliver your project, get in touch with our team today.

Authors

Subscribe to our newsletter

Be the first to hear about what’s hot in e-commerce and Shopify Plus. Straight to your inbox.