From monolith to headless commerce…in real life !

Headless commerce works with a backend decoupled from the frontend (which calls the backend for business rules), enabling, among other things, omnichannel capabilities. Compared to monolithic e-commerce systems, it comes with many benefits, but also some drawbacks. It’s an architecture type that’s currently getting a lot of attention, but behind the technical buzzword, what are the implications of migrating to headless from a monolith ?

Migrating to headless in practice

First step : setting up APIs

The monolith is often used only with its APIs (sometimes many of them), without its frontend: the frontend and backend are thus decoupled.

For the frontend, you can either choose to build something custom or to use open source. This first step allows you to improve user experience, interface fluidity, and mobile experience. You can already consider connecting these APIs to interactive kiosks or checkout systems.

However, this first step has some drawbacks :

• The backend remains a monolith, as a single codebase does everything.
• The frontend connected to the APIs is highly dependent on them: if they change, the frontend will break and stop working. Both need to continue evolving at the same time.
• The system is still dependent on the performance scalability and stability of the APIs, which is still provided by the monolith.

Second step : introducing a backend for frontend

Major e-commerce players often choose to introduce a backend for frontend between the monolith’s APIs and the interfaces or different channels (frontend, mobile, checkout, kiosks…) : this intermediary element acts as a translator between the two worlds, legacy APIs, and user interfaces. Thus, the different channels never communicate with the monolith’s APIs, but only with the backend for frontend: by communicating via independent an API, the frontend can ignore the old APIs.

This solution allows the backend to evolve independently from the frontend, allowing you to plug in or remove certain APIs and dismantle the monolith with regard to an unwanted element (for example products), all without touching the frontend. The most common backend for frontend solutions include, among others, Apollo, AWS API Gateway, or Spring Boot.

But beware, this approach introduces new complexities. It’s a layer cake that keeps growing, requiring mastery of new technologies and producing a “generational shock.”

The impacts of migration

Certain trends are evident among the top-20 e-commerce major players.

On the organizational side, there are frontends (for example React) that communicate with APIs, or server-side rendering (the generation of html pages on the server side, for an optimal user experience), then backend for frontend solutions like Apollo, and Identity Access Management (IAM). Finally, coupled with the backend for frontend solution, there are different types of databases and legacy APIs (ERP, business APIs, content management tools, e-commerce tools…).

As a result, the e-commerce backend becomes tiny compared to the whole technical ecosystem, which then requires engineering.

This operation also brings engineering on the frontend side, which must be very carefully designed for high performance and user experience, but also to locate the cold data (daily or hourly prediction) and hot data (often evolving by the minute which requires calling and calculating it each time).

The user experience is then built according to these hot and cold data. This sorting operation can be performed by a search engine, or by a business API, reasoning case by case to locate the data and label it. The advantage of monoliths is that they avoid these extra steps.

Encapsulation

It is possible to consider migrating, that is to say adding an e-commerce component to the frontend, without changing the rest of the system by encapsulating a piece of new page within the old system.

This new engineering option consists of encapsulating several frontends into one, called the micro-frontend.

For the internet user, this method is perfectly “seamless” : they see only one screen, which is actually a composite of elements coming from several places.

This approach is practiced by major players, who rebuild their pages piece by piece, when it is unthinkable to redo the entire frontend all at once.