What is Headless Commerce? And why do you need to know about it?

What is Headless Commerce? And why do you need to know about it?

Introduction of Headless Commerce for developers

ยท

10 min read

Why Every Business Needs A Website - Forbes

Let's skip the "internet has changed the way we shop" part and get straight to the point. All of us, or at least most of us, visit eCommerce websites a few times a week. Whether we are checking for clothes, household goods, gadgets, or, well, almost anything, we will immediately Google it or visit the online shop we love. The number of online shops is growing and it's almost impossible for a business in commerce to survive without an online presence...

rolling eyes

Aaaand....somewhere here most of the developers reading this would say something like: "bruh, why am I even reading this business nonsense" - I know, stay with me, soon we will get to a juicy part ๐Ÿ˜‰

To be clear - more websites to be built, more developers needed, and more ๐Ÿ’ฐ๐Ÿ’ฐ๐Ÿ’ฐ to be earned. But how Headless can help you with this?

Why monoliths can be problematic at scale

A long time ago, when mammoths were still roaming around, most eCommerce websites were built in a so-called monolithic architecture. Traditionally monolith architecture was the most popular approach. It was pretty simple to build and deploy, but the moment you would want to introduce new features, it was becoming harder and harder.

Usually, these were custom monorepo projects, the backend tightly coupled with the frontend, and any significant change would require a change on both sides. Since both presentational (read Frontend) and application layer (read Backend) were so dependent on each other, the failure of one could lead to the failure of the whole application. Because of this, very thorough testing was required. On the other hand, when the application was growing in size, it was becoming harder and harder to maintain it.

This leads us to another issue: the hiring of the development team. You would need to hire developers with a very special skill set to be able to contribute to the application development process.

typical monolith architecture developer

Targeting some of the pain points, WordPress jumped in and dominated the market. It was a great solution to many problems: built-in CMS, storefront themes like what WooCommece provides, and a crazy amount of plugins you could connect to your application. If you want a payment plugin, plug it in (pun intended) and here you are - you have a payment system connected. Do you need internationalization? It's here, take it!

Sounds like a dream, ha? Well, to some extent. The issue with WordPress is that if you're not careful (let's be honest, even if you are), the more plugins you connect, the slower your website will become. Another issue is the themes. Even though there are tons of different themes and they are still increasing in numbers daily, only a few dozens are really good and many eCommerce websites seem to be very-very similar visually. You can customize them of course, but if you have ever customized a theme, you know how painful it is.

Tho, I would be biased if I don't say a few good things about WordPress ๐Ÿ˜ It was a game changer for its time, it was fairly easy to build and set up and business owners could even do that on their own or hire a developer if they could afford.

So, hey, it sounds pretty awesome, why would anyone need to do anything else? And here's why.

The head is the problem - the Omnichannel issue

The monolith architecture applications like WordPress were relatively okay for the web, but they were not suitable for any other mediums. When the business grows, it may require additional customer channels: mobile applications, Socials, IoT applications, VR/AR applications, etc. Every business owner would like to create as many customer touchpoints as possible, but our tightly-coupled model does not work here. Traditional monolith eCommerce just can't scale to cover all possible channels. For each of these channels, businesses would have to create a separate application layer, they would be lucky if at least they can share a database between these new applications.

This sounds like an opportunity for something big, don't you think so? What if we get rid of the head? And by saying this, I don't mean that we don't need a Frontend now, but what if we make an application, that would function well without relying on the Frontend at all? What if we create a set of APIs that would communicate with any form of the Frontend, whether it's Web, Mobile App, etc?

Getting rid of the head - Introducing Headless Commerce architecture

This is where the idea of Headless Commerce was born. It's a relatively old term, dating back to 2013, but it started to get traction only recently. In the essence, Headless Architecture's mission is to decouple the Frontend from the Backend and introduce the APIs as the main way to communicate between both. By doing so, we are free to decide what technology to use for the Frontend, how will it look and feel, what content we want to display, and what Frontend to use (web, mobile, etc) without disturbing the application layer.

In a perfect world, that would mean that creating a Backend once, will suit the needs of any Frontend.

The monolith architecture is not future-proof, especially if we are talking about such fast pace industry as eCommerce. Monoliths make you and your business a tech stack hostage, when something new pops up on the market you almost always have to recreate the application from scratch. Nowadays it's too risky to put all your money in the same bag. On the other hand, with headless architecture, your eCommerce platform is just another API to connect with your application.

So, what does modern Headless Architecture looks like? Like a sandwich!

biting sandwich gif

Usually, the Headless Architecture consists of the following:

  • Custom Frontend or Frontend as a Service (Vue Storefront is the best one, but I can be biased ๐Ÿ˜‰)

  • Headless Commerce platform (commercetools, Shopify, etc)

  • Headless CMS (Contentful, Storyblok, etc)

  • Search, Payment, and more (Algolia, PayPal, Stripe, etc)

In the image below you can see the Architecture of the Vue Storefront application, representing FEaaS, that connects to the different providers like eCommerce platform, CMS, Search, Authentication, and more through built-in Server Middleware - an API orchestration layer to manage requests.

Data flow between the browser, Server Middleware, it's extensions and integration platforms

You can learn more about the Network Architecture on the official docs website - Vue Storefront Docs - Networking

Headless Commerce components

Let's take a look at each of them from the developer's perspective ๐Ÿค“

Frontend

Since our application is decoupled, we are free to choose any Frontend to our liking.

The frontend can be a ready-made template, a completely custom solution, or a Frontend-as-a-Service. Well, the first two are pretty obvious, but what is this FEaaS?

When you're building an Enterprise level eCommerce solution, there is a lot of things to build! Typically, you would have to integrate your Headless Commerce platform, Headless CMS platform, Search, Payment, and Authorisation providers, and many many more. Oh, don't forget about performance, SEO, Internationalization, Accessibility, and hosting ๐Ÿคฏ

This is huge work and requires a lot of time to architect it well and execute. This is where FEaaS platforms come in handy - they provide you with a set of built-in solutions to connect to any of those services via a set of easy-to-use modules, instead of building it all from scratch. This not only saves tons of work but also gives you the best-in-class security and performance.

We as developers are getting modules and code that we can use to build full-blown eCommerce applications faster and easier. Think of it as an SDK that allows you to connect to most of the platforms and services just like we are using the Supabase SDK, or Firebase SDK. Sounds cool, ha? ๐Ÿ˜

Another great advantage of FEaaS is that it allows a relatively seamless transition from one vendor to another (commerce platform, CMS, etc)

Headless Commerce platforms

So what are those? Well, you can think of it as an API-first backend for the eCommerce application. Usually, these platforms provide a set of tools to manage everything you need for your shop, just like monolith did, but instead, they expose an API interface to consume only those parts of the functionality that you need.

They are responsible for the product's name, description, images, pricing, variants, IDs, and so on. This is the heart of the eCommerce website. Some platforms provide more functionality than others and it's up to businesses to decide which one to choose.

What is important to us, developers is that all Headless Commerce platforms provide APIs that we will use to communicate with on our Frontend. Most of those platforms provide amazing documentation and are easy to connect.

In very short, it's a Backend ๐Ÿ˜‰

Headless CMS

These are something a lot of us have heard, some may have used them for their Blog websites, or something else. Out of all that we have listed above, these are the most common in the day-to-day life of a developer. It's a content management system, that we don't need to host, we just use their APIs to get the data and display it on the Frontend.

Well, if you think about it, GitHub is some sort of Headless CMS too ๐Ÿ˜‚

With Headless CMS content managers can create complete pages or only part of pages without the need for a developer to customize Frontend. Set it up once, fetch and render content and let content managers do what they do best.

Other integrations

Even if I wanted, I wouldn't be able to cover even 10% of all possible integrations and 3rd-party services you can connect to your eCommerce website. But let's just cover the basics.

  • Search

    Have you ever created a search on a website? Most probably yes. Was it painful? Well, maybe yes, maybe no. Have you ever created a search for an eCommerce website, where each product can be found in 10-20 different ways? If yes, you know how painful it is. This is where SaaS companies like Algolia and others come to the rescue. Plug it in, connect with the API, search is ready ๐Ÿฅณ

  • Authentication

    Are there still developers who want to create custom-built authentication? Idk, don't think so. Authentication is an extremely tough topic, it's very critical for the business, and overlooked security breaches can cost millions of dollars, so it almost became an industry standard to use SaaS providers like Auth0, and many others. The idea stays the same, plug it in, connect with the API - profit ๐Ÿ˜

  • Payment

    Do I need to say something about it? "Online Merchants Lose 62% of Customers Who Experience a Failed Transaction" - yeah, definitely it's better to rely on a trusted payment provider.

There are tons of different integrations available on the market, and some research has to be done for sure, but the most popular and trusted providers are widely used by many businesses. They usually have easy-to-understand documentation and straightforward APIs.

Headless Commerce is the future (?)

It's not for me to decide, eCommerce is a multibillion-dollar industry and any mistake can lead to huge losses. But the recent trends show the rise of Headless Commerce, or as it is also called Composable Commerce in the Enterprise sector and us, developers, should be aware of what is coming if we want to ride the wave.

Same as technologies evolve and improve over time, the market is evolving too. And we need to adapt to the market to be in high demand as always. I'm sure, that soon we will see even more Headless SaaS services with the increasing quality and awareness of AI technologies.

AI assistant, to do the shopping for you? AI search and suggestions on the websites? AI content managers? Sounds quite possible if you ask me. Headless Architecture works best with this kind of tool. Plug it in, connect with API, and here you go, you have an AI assistant on your eCommerce website.

I hope this article was useful for you, developer. If you have some questions left, connect with me on Twitter or ask them in the comments below ๐Ÿ˜

Let me know if you're interested in this topic and I will make it a series ๐Ÿ˜‰

Did you find this article valuable?

Support Sergii Kirianov by becoming a sponsor. Any amount is appreciated!

ย