Headless architecture, explained without the hype

What headless architecture actually is

Headless architecture is a way of building software where the user interface and the business logic are separated and communicate through APIs. In ecommerce specifically, the "head" is the storefront a customer sees. The body is everything else: catalog, pricing, cart, checkout, orders, customer accounts, fulfilment. In a headless setup these are two independent systems that talk to each other over the network, not two halves of the same application.

The term was popularized in 2013 by commercetools co-founder Dirk Hoerig, but the underlying pattern is older than that. APIs separating presentation from logic is how most modern software is built. Headless commerce is the application of that pattern to ecommerce platforms, which historically shipped the storefront and the backend as a single codebase.

How it differs from monolithic ecommerce

A traditional ecommerce platform like Magento 2 with the Luma theme, Shopify with a Liquid theme, or BigCommerce with Stencil ships the frontend and backend as one application. Pages are rendered on the same server that processes orders. The theme is a folder inside the same codebase as the checkout. Updating one usually means deploying the other.

Headless flips that. The storefront becomes a separate application, often written in React, Vue, or another modern frontend framework, hosted independently of the commerce engine. It fetches product data, cart state, and order information through APIs. The commerce engine itself does not render any HTML. It just answers API calls.

This is not subtle. It changes how the team is organized, how deployments work, what infrastructure you pay for, and what kinds of customizations are easy versus expensive. It is not a feature toggle.

The layers in practice

Most production headless commerce systems have four distinct layers. The names vary by vendor, but the responsibilities are similar.

Presentation layer

The storefront itself. The Nuxt, Next.js, Remix, SvelteKit, or Astro application that renders pages and runs in the customer's browser. It owns the design system, the routing, the SEO behavior, and the user interaction. It does not own any commerce data.

Backend-for-frontend (BFF) or orchestration layer

A server-side layer that sits between the storefront and the commerce engine. It composes data from multiple backend services, caches what is safe to cache, and presents a clean API tailored to the storefront's needs. Alokai calls theirs Middleware. commercetools Frontend has a similar concept. A well-built BFF is what makes a headless storefront fast and stable.

Commerce APIs

The actual commerce engine: Norce, Shopware, Magento, Shopify, commercetools, BigCommerce, Centra. These expose REST or GraphQL endpoints for products, prices, inventory, carts, checkout, orders, and customer accounts. The frontend talks to them only through the BFF.

Adjacent services

Search (Meilisearch, Algolia, Hello Retail), CMS (Storyblok, Sanity, Contentful), payment providers (Klarna, Walley, Vipps, Stripe), reviews (Lipscore, Trustpilot), CRM (Voyado, Klaviyo, Rule), shipping (nShift, Ingrid), and analytics. Each is independent. Each integrates through the BFF.

The pattern is the same regardless of which vendor you pick at each layer. That portability is the whole point of headless.

What headless gets you

The honest list of benefits is shorter than most vendor pages suggest.

• Frontend independence. You can change the storefront without redeploying the commerce engine. You can also change the commerce engine without rebuilding the storefront, provided the BFF abstracts the difference well.
• Multi-channel reach. The same commerce APIs can power a web storefront, a mobile app, a kiosk, a voice interface, or a customer service tool. None of them shares code with the others, but they share data.
• Best-of-breed integrations. You pick a separate search vendor, CMS, and payment provider. You are not stuck with whatever the platform ships in the box.
• Performance ceiling. A purpose-built frontend on an edge runtime (Vercel, Cloudflare, Oxygen) can be faster than any monolithic platform's theme layer. Whether you reach that ceiling depends on how well the BFF caches data.

What headless costs you

The costs are real and most vendor content underplays them.

• More moving parts to coordinate. A monolithic Shopify or Magento install is one system. A headless setup is at minimum four (frontend, BFF, commerce engine, CMS), usually six to ten once you add search, payment, CRM, shipping, and reviews. Each is a separate vendor, a separate contract, and a separate failure mode.
• Engineering investment. Building and operating a headless storefront from scratch is a real software project. The teams that succeed have either in-house frontend engineers or a delivery partner with deep headless experience. The teams that struggle assumed headless would be a configuration exercise.
• Slower change for some things. Adding a new checkout step or a new product attribute often touches multiple layers (commerce engine, BFF, frontend), each requiring a deploy. On a monolithic platform a small theme change is one deploy.
• Operational ownership. The frontend is yours. Hosting, scaling, monitoring, security patching, and dependency upgrades are now part of your operation. Some hosting platforms (Vercel, Oxygen) abstract most of this, but it does not vanish.

When headless is the right call

Headless makes sense when:

• You sell across multiple channels and want them backed by one product catalog and one cart.
• The storefront experience is a real competitive differentiator. Custom UX, unusual product configurators, B2B-specific workflows, branded checkout.
• You expect to outgrow or replace the commerce engine within a few years, and you want the frontend investment to survive that move.
• The team or delivery partner can sustain the operational complexity. Either you have the engineers, or you buy them.

When monolithic is still the right call

Monolithic is the better call when:

• Volume is moderate, the storefront is reasonably standard, and the team is small. A well-built Shopify or Magento store with a quality theme outperforms a badly-built headless storefront on every measure that matters.
• Speed to launch is the dominant constraint. Themes ship faster than custom frontends.
• You do not have a dedicated frontend team and your delivery partner is more comfortable in monolithic platforms.
• The integration set is straightforward and fits inside the platform's app store.

Going headless to follow a trend, with no clear competitive reason and no team to operate it, is the most common way headless projects fail. It is not a step everyone in ecommerce needs to take.

Where frontend-as-a-service fits in

A frontend-as-a-service (FaaS) product packages the storefront layer and parts of the BFF layer as a productized offering. Instead of building the frontend from scratch you license a working frontend, customize the design and content, and connect it to your chosen commerce engine.

Frntkey is a frontend-as-a-service. It ships a Nuxt-based storefront with pre-built integrations for Norce Commerce, Shopware, Storyblok, Klarna, Walley, Vipps, Voyado, Hello Retail, Lipscore, and others. The BFF layer is included. Hosting on Vercel is included. The Storyblok CMS is bundled. Implementation is delivered by Nordic Web Team.

FaaS is not the right answer for every project. If the storefront is so distinctive that a packaged frontend would have to be rewritten anyway, a fully custom build (on Alokai, Hydrogen, or a bespoke Nuxt or Next.js app) is more honest. If the project is small enough that headless is overkill, a monolithic platform with a good theme is better.

Where FaaS earns its place is the middle: serious headless commerce projects on Norce or Shopware that need a production-grade storefront in months, not quarters, without rebuilding solved problems from scratch.

The honest summary

Headless architecture is a real, durable shift in how ecommerce software is built. It is also more work and more cost than vendor marketing suggests. The decision to go headless should rest on what the storefront has to do that a monolithic platform cannot, not on whether headless is fashionable.

If the answer to that question is clear, the next decision is delivery model: fully custom, frontend-as-a-service, or platform-native (Hydrogen for Shopify, Hyvä for Magento). Each has a different ceiling and a different cost curve. The right choice is the one that matches the team you have, the backend you are committing to, and the storefront experience the brand needs.