💻 Development

Headless Commerce

headless commerce · headless ecommerce · headless e-commerce · decoupled commerce · api-first commerce · composable commerce

Definition

Headless commerce is an architecture that separates an online store's frontend from its backend through an API; it simplifies integrating personalization, search and analytics as independent services.

What a headless architecture is

In a traditional platform — Magento, WooCommerce, OpenCart — the frontend and the backend are one application. Page templates live inside the CMS and presentation logic is entangled with business logic. Any change to the storefront goes through the platform’s own development cycle.

In a headless architecture the head is cut off: the frontend is a standalone application (React/Next.js, Vue/Nuxt, a mobile app) talking to the backend purely through an API. The backend becomes a set of services with API interfaces.

Monolith:                Headless:
┌─────────────────┐      ┌──────────────┐     ┌──────────────────┐
│ Frontend        │      │ Next.js SPA  │     │ Commerce backend │
│ + business logic│      │ (storefront) │────▶│ (catalogue,      │
│ + data          │      └──────────────┘     │  orders)         │
└─────────────────┘             │             └──────────────────┘
                                │              ┌──────────────────┐
                                └─────────────▶│ Personalization  │
                                               └──────────────────┘

What it gives integrations

Headless makes it easier to connect outside services — personalization, search, analytics — as independent API components. There is no plugin to embed in a monolithic platform: the service is called from the backend for frontend on the server, or from JavaScript in the browser.

What is being integrated	Headless (server-side)	Monolith
Personalization	An API call in the BFF before rendering	A JS snippet after load
Search	A call to the search API, then render	A plugin for the platform
A/B test	A feature flag at BFF level	A JS snippet, with flicker risk

Server-side against client-side in headless

Server-side integration is the preferred route for personalization in headless:
– The BFF fetches recommendations and the user profile before the HTML is served
– The visitor sees personalized content immediately, with no flicker or layout shift
– Good for Core Web Vitals and for indexing personalized pages

Client-side integration is simpler, with limits:
– The JavaScript snippet loads after the first render
– Content swapping produces a visible flicker and layout shift
– It works for dynamic widgets where indexation is not critical

When headless is justified

A headless architecture makes sense when:
– The storefront has to exist on several channels at once — web, mobile app, in-store kiosk
– The team wants to deploy the frontend independently of the platform’s release cycle
– Maximum freedom in customising the experience is required
– There is a dedicated frontend team of two or more developers

For an SMB without those conditions, headless adds complexity without proportionate benefit.

Tip: when costing a move to headless, count not only the development of the storefront but the running costs — headless needs its own deployment, monitoring and frontend support.

Frequently asked questions

How does headless differ from a monolithic platform?

In a monolith such as traditional Magento the frontend and the backend are tightly bound — a change to the storefront means a change inside the platform core. In headless the frontend, a Next.js app or a mobile app, talks to the backend only through an API. That brings development speed and independent scaling, but it needs a frontend team of its own.

How does personalization fit into headless?

There are two main routes: server-side, where the backend for frontend fetches recommendations and the user's segment before rendering the page; and client-side, where a JavaScript snippet loads in the browser and swaps content after the first render. Server-side is better for Core Web Vitals because there is no layout shift, and harder for in-session personalization.

Does headless commerce imply GraphQL?

No. Headless is a principle of separation through an API, not a specific protocol. Plenty of headless architectures use REST. GraphQL is popular in headless precisely because the client controls the response shape, which helps with complex aggregation across several services.

Who does not need headless?

Stores with no dedicated frontend team and ordinary customisation requirements. A monolith on a modern SaaS platform such as Shopify or BigCommerce, with personalization plugins, covers most SMB needs faster and more cheaply.