Usually headless is understood as the independence between a Frontend and a Backend and their communication through the API. But I would like to discuss it in more detail in this article. Let's stay focused on headless philosophy as a business approach.

How headless architecture emerged

When I have learned about the headless for the first time, it wasn't applied to CMS. Once in an article, I read about an American company that sews jeans for millions of people every day. Of course, this is not the only denim giant in the world. Its uniqueness arises from the fact that the company did not sew anything. It employed 20 staff only. What can 20 people produce? All business processes were outsourced. One contractor was responsible for the design, another one for production, and the third one for delivery. Moreover, the financial department was outsourced.The only function that was lead by the head office was managing these processes.

This business logic surprised me.And even back then, there was a feeling that the e-commerce market would be developing in the same direction.

Over time, services have begun to emerge that allows e-commerce businesses to delegate individual functions to outsource.

For example, Avalara is one of those. It is a service for global e-commerce. Different countries have different taxes for the same products. Avalara determines the tax rate for a product depending on the country where the site user makes a purchase. Isn't it convenient? There is no need to save/update data about the taxes of all the countries which are being sold by the website on your side. Avalara will do everything. The user selects the product on the website, puts it in the basket, after that the Avalara service responds to a system (through the API) about the product tax.

The number of such services increased a lot. This allowed the e-commerce projects don't integrate separated functions intothe Backend.

For example, we often use Algolia to search the site in our projects. Anything the user types in a search line is not found by Magento, but Algolia. How it works. the online store gives all the product data to the cloud service in advance.

Magento communicates with a search through the API. Algolia is applied to any online shop as well as any CMS. As an alternative, there is a search service called Searchanise. According to our data, half of the large e-commerce projects already use a cloud search rather than a built-in solution.

Comarch Loyalty is another example. It helps businesses to manage personalized loyalty programs. At the time of purchase Comarch product aggregates bonuses and discounts. This service sends the information through the API both to an offline point at the checkout, to the online store (mobile application). There could be many channels of communication with the user.

Another cool product is a Storyblok. It is a mix of headless CMS and a page builder. The most beautiful content can be created via a convenient interface. It works as a cloud-based page builder, but at the same time does not have its frontend. So it transfers data to the Frontend of the online store through the API.

As a result, many business tasks can be delegated to independent software products. Often it is the cloud service.

How does the logic of headless commerce look like in practice

Take a look at this diagram. CMS as a center of the interaction for all elements no longer exists. There is no concentration of all instruments or even data in one place. Some basic data is saved on the Backend: prices, sales, catalogue. But PIM (Product Information Management) and CRM (Customer Relationship Management) can be integrated into the Backend. Inventory Management Systems also use a headless model, as management systems often use a headless model to automate processes for warehouse management. since warehouse management often uses a headless model to automate processes you need special software.

The traditional understanding of the Backend is changing. The headless architecture implies that the Backend can pass through the API data to other elements of the system. As soon as PWA technology appeared in Magento, the CMS became headless. The Frontend can work independently from the Backend.

Let's take a look at this example. is an online store that needed a migration from Magento 1 to Magento 2. The Frontend was deeply integrated into Magento 1. Firstly, the developers implemented PWA by making a headless model. Then we changed the Backend to Magento 2. Thus, there was no “abrupt transition” during migration.

It is necessary to change the business architecture to headless...

  • if the marketing is user or content focused .

    Today, businesses are taking an omnichannel approach. Provides a quality user experience regardless of the channel communication with the brand: whether it be a mobile application, website or social network. If the customer typed in the online store points, you can spend them both on the website and offline.

  • if the business operates in the international market.

    Globality and multichannel are the main reasons to change the business architecture to headless. Online shopping like usually targeted at sales in several countries. Each country has its own specificity of the market. Somewhere better to sell through social networks, somewhere through a website or mobile application, and in the USA, for example, through Amazon. Complicated logistics and tax accounting is pushing for a distributed business model.

  • if you need to ensure stable business development

    The headless architecture will protect e-commerce from disruptions. If there is a problem with some service, for example, a search engine, it is easy to replace it with another one. In the headless architecture, it communicates with the Backend through the API. Developers do not need to redo your product to Magento. The core remains. The headless architecture reminds me of a case with a modular smartphone ARA. Each component is replaceable. It is providing new business opportunities. When the Frontend is not well integrated with the Backend, replacing one with the other is much easier.

How have developers' tasks been changed?

If it seemed to you that the range of tasks for developers has narrowed, you are wrong. Headless architecture connects elements with many intersections. It reminds the picture on the right.

It's good when the APIs are the same. But in practice, you have to use multiple APIs. Our task is to «friend» all the elements and to set up their work in a complex.