Headless E-commerce: What, Why and How
Paul Grieselhuber
In our recent article on user authentication options for Shopify stores, we shared our guidance on selecting an authentication strategy for Headless e-commerce stores. It provides a framework to use when analyzing this important aspect of your site as your needs change as a result of your business's growth.
But what exactly is a Headless e-commerce store? It helps to start by understanding how a basic e-commerce store would normally be structured. It more or less boils down to this: the backend and frontend of your stores live within one service:
- Products
- Inventory
- Orders
- Interactions
- Layouts
- Interactive elements
A simple way to think about it is demonstrated here:
The standard is a standard for a reason
This setup is very much the standard for new e-commerce stores, and it is a great way to get started: you sign-up for a plan with Shopify, select a theme, install it with a click, customize it with your logo and colors, add products and start selling.
You can go quite a bit further with the third-party app ecosystem to really extend the capabilities of your store. Some apps are built very well and are impressive products in and of themselves (note: some…).
This standard is tried and true, with very few barriers to entry. So what’s the problem?
If you need a very simple e-commerce store - absolutely nothing.
Are you selling mugs and t-shirts and just need a place to let customers view your products and checkout? Look no further than this standard.
So how and when do you decide to depart from the standard?
It is very often a “feel” thing. Running your store, frontend and backend, according to methodologies and tool kits defined by other teams for companies who are not yours ends up stacking friction that eventually takes a toll on your business.
When this sounds a bit too much like you and your business, it’s time to go headless.
What is a headless store?
A headless store is one where your own application serves the storefront or “frontend” of your site, while fetching data from Shopify via their APIs.
For example, part of the code for your product template for a headless store might look like so:
<h1>{product.title}</h1>
As you can probably guess, product.title is a variable which will be replaced with the real title of your product when someone views the page.
How does the template know what to show?
Your application requests the information on a given product from Shopify via their API (computers which respond with data structures instead of full pages), and Shopify responds with the attributes of your product, including the title.
For instance your application would make a request to (this is a fake URL):
https://www.shopify.com/your-store/products/123.json
This URL would respond with data something like this:
{
"title": "16 oz. Unbreakable Blue Mug",
"price": "24.99",
"inStock": 59
}
So the result of the code above would end up looking like this:
<h1>16 oz. Unbreakable Blue Mug</h1>
Okay…
So why are we giving up the simplicity of Shopify templates for the complexity of building our own application.
This goes back to that “feel” thing. When you know that with the right tooling built around your business would let you run it more efficiently and with less friction, or would let you allocate aspects of your business to task specialists instead of the leadership of your business - again: headless.
With such a setup, you still rely on the power of Shopify’s e-commerce for “backend” tasks like managing products, inventory, discounts, refunds, etc. But by treating Shopify as “just a backend” you free yourself to build anything you see fit, and to easily adapt your approach to e-commerce as your needs and inspiration grow.
Here is a rough idea of how this would look:
Why might you consider a headless store?
There can be many considerations which tilt in the direction of going headless. Here are some of the most common cases where people select a headless store
- The e-commerce store is only part of the website, and lives alongside other content
- The owner has previous experience working with Liquid, and knows its limitations
- Avoiding vendor lock-in with one e-commerce vendor - with headless stores you can change the entire backend while the frontend remains untouched. This aspect must be at least part of the reason why Shopify developed their Hydrogen and Oxygen stack. Just when you thought you were out...
- You have complex integrations with many systems and are tired of logging into 5-10 different platforms to gather the metrics you need to run your business.
- You are developing an e-commerce marketplace where many sellers will be participating, and therefore it is impractical to give each access to the canonical Shopify admin for the marketplace
What are the benefits of going headless?
Decoupling
Decoupling the core of your store, marketplace, booking solution, etc. from the e-commerce platform provides many benefits to business owners.
It allows you to focus on delivering the product that is needed to power your business without focusing on how your platform does things. The e-commerce platform (Shopify, BigCommerce, etc.) are there to process sales, organize your products into collections, etc.
There is simply no need to make them a fundamental part of the entire breadth of your product.
The ideal case is that the API methods used to interact with these platforms abstract out as much of the platform-specific dependencies as possible, so that the platforms become interchangeable. A tall order, no doubt, but a worthwhile objective nonetheless. Even getting only half-way there would lower switching costs and empower you to stay focused on your outcomes vs. their features / structure / APIs, etc.
This topic alone goes quite broad, and we may do follow-up posts on it. Follow us if you would like to see more on this subject and leave us a comment.
Leverage existing in-house competencies
As Shopify mentions in their post on the subject, headless applications can be written in any language and with any infra you like.
If you do have an in-house technical team and they do not happen to be Liquid developers (not a super common situation in our experience), you can continue to rely on their expertise and your existing processes.
What are the costs of going headless?
Headless tends to mean greater technology costs. Liquid engineering expertise is inexpensive and common. This is why we only suggest going headless when the scale of your growth can support the additional expense of a more-capable-yet-more-complex operation.
Summary
As we mentioned, it's very much a "feel" thing as far as whether headless is right for your e-commerce business. The answer changes with time and scale. There are very few large businesses who should be still running on Liquid, as the opportunity cost is quite substantial. That said, it is product dependent at to whether headless is the right choice for small or new businesses.
If you want help deciding whether headless is right for your business, reach out to us. We'll be happy to discuss your current situation and make a recommendation for future technology planning.
