If you walk into a modern retail engineering org, nobody is talking about “templates” or “liquid customisations.” They’re talking about React Server Components, streaming on the edge, data hydration, cache invalidation, and how to stitch multiple backend domains into a single customer experience.
In that world, the old assumption - that the e-commerce platform should own the storefront - doesn’t hold anymore. Not because storefronts don’t matter, but because storefronts have become software, not CMS skins.
Which is why headless storefronts built using frameworks like React, Next.js, Remix, Nuxt, SvelteKit and others are becoming the default choice for serious ecommerce teams.
The interesting part isn’t the frameworks. It’s the architecture that makes those frameworks viable for commerce at scale.
Why Headless Happened: The Business Outgrew the Theme Layer
The shift to headless wasn’t driven by engineering fashion. It was driven by business requirements that theme-based monoliths could no longer satisfy.
Teams hit the same ceiling in different ways:
Performance pressure (Core Web Vitals, SEO, conversions)
Design differentiation (no more “every store looks the same”)
Feature parity across channels (web, mobile, kiosks, POS)
Experimentation velocity (A/B tests without theme restrictions)
Data-driven experiences (real-time availability, personalised pricing)
Modern deployment models (edge rendering, server components)
Themes weren’t built for these. Frameworks were.
But switching to a framework is easy. Running commerce through it is not.
That’s where most companies discover the gap: the backend domain logic isn’t ready for headless.
The Architecture Problem: Commerce Data is Not Page Content
When teams first adopt headless, they discover that the frontend doesn’t just need “product data.” It needs live business data:
inventory availability
variant selectors
contextual pricing
promotions
tax localization
cart state
checkout orchestration
Rendering a PDP (Product Detail Page) is not the hard part. Hydrating that page with real-time state across devices, channels, and contexts is where complexity appears.
This is why headless architectures require API-first commerce backends, not CMS plugins pretending to be APIs.
React, Next.js, Remix, or SvelteKit can’t fix backend coupling. They can only reveal it.
Frameworks Are Not Commerce Systems — They Are Orchestrators
Look at how each major frontend framework approaches server-client orchestration:
React Server Components (RSC) → streaming UI around server-side data
Next.js App Router → layout-level data fetching + caching + edge SSR
Remix → loaders/actions for request-scoped mutations
Nuxt/SvelteKit → server load functions for API-fetching
Expo/React Native → client-driven fetches for app flows
None of these frameworks assumes a monolithic backend exists. They assume composable APIs.
In practice, this means the frontend expects commerce to behave like microservices:
GET /catalog/:id
GET /pricing?sku=X&customer=Y
GET /inventory?sku=X&location=Y
POST /carts/:id/items
POST /checkout
If the backend cannot expose these surfaces cleanly, headless turns into middleware spaghetti instead of a productivity boost.
The DX Unlock: Data Domains, Not Pages
Teams doing headless well don’t organise code by pages. They organise it by domains.
A typical frontend integration looks like:
domains/catalogue/
domains/pricing/
domains/inventory/
domains/cart/
domains/checkout/
Pages become orchestrators:
app/product/[slug]/page.tsx
app/cart/page.tsx
app/checkout/page.tsx
Each page hydrates from domain APIs, not from CMS templates.
This is how engineering teams align with modern commerce: the data model becomes the contract and the UI becomes a composition layer.
What Breaks Without an API-First Commerce Backend
Many teams learn the hard way that headless is not just “API calls from React.” Without domain-specific commerce APIs, engineering is forced to build its own backend abstractions:
Pricing rules in middleware
Inventory polling scripts
Cart logic in serverless functions
Custom checkouts with partial state
ERP sync queues
Ad-hoc fulfilment events
Suddenly, the team is maintaining a shadow commerce system outside the platform.
This is the point where engineering leaders realise the storefront rewrite was the easy part - the commerce backend is the bottleneck.
Why Commerce Engine Works With Modern Frontend Frameworks
Commerce Engine doesn’t try to render storefronts. It exposes domain primitives that make storefronts possible:
/catalog
/pricing
/inventory
/carts
/checkout
/orders
Each service:
Returns normalized JSON
Has documented contracts
Supports idempotent mutations
Emits order/inventory events
Scales independently
Doesn’t assume a session
This matters because frameworks like Next.js, Remix, Nuxt, and SvelteKit expect stateless, fetchable primitives.
A product page becomes:
const product = await fetch(`/catalog/products/${id}`)
const price = await fetch(`/pricing?sku=${product.sku}&customer=${ctx}`)
const stock = await fetch(`/inventory?sku=${product.sku}&location=${ctx}`)
Hydration becomes deterministic instead of “theme-driven.”
Checkout Is Where Framework Choice Really Matters
Checkout is not just UI. Checkout is the hardest boundary because it touches:
PCI scope
Payment intents
Tax rules
Fraud checks
Shipping quotes
Inventory reservation
Discount evaluation
Multi-address shipments
Partial fulfillment
When checkout is API-first, frameworks can handle UX without touching compliance.
Commerce Engine exposes checkout as a workflow:
POST /carts/:id/items
POST /checkout
POST /payments
POST /shipments
Next.js or Remix can orchestrate these as server actions or mutations.
This is how modern teams avoid building checkout twice for web and mobile.
Experimentation Velocity: The Often Ignored Reason to Go Headless
Most companies don’t go headless because they need server components. They go headless because they need marketing velocity without platform debt.
Common cases:
A/B test product card layout
Device-specific PDP components
Region-specific tax banners
Real-time inventory badges
Loyalty pricing overlays
Dynamic bundling
Shoppable content
In monoliths, these require:
Plugin installs
Theme overrides
Deployment freezes
In headless, these require:
Feature flags
Server actions
Edge caching rules
The difference is organisational, not technical.
The Teams Adopting This Pattern Aren’t Just D2C Startups
The stereotype is that headless is for small D2C brands trying to “look cool.” The reality is the opposite.
Headless is becoming the default for:
Mid-market retailers expanding internationally
Manufacturers adding D2B commerce
Enterprise B2B portals needing contract pricing
Marketplace operators with multi-tenant models
Omnichannel brands syncing POS + web + app
Grocery chains with real-time inventory
Automotive, electronics and industrial distributors
Pharma/med supply with regulated catalogues
These teams outgrow theme-based systems because commerce becomes software, not content.
The Takeaway
React, Next.js, Remix, Nuxt, or SvelteKit are not why headless works. They are why headless is finally viable.
The real enabler is an API-first commerce backend that exposes domain boundaries cleanly enough that frontends can orchestrate without rewriting commerce logic.
The moment commerce becomes composable at the API layer, frontend frameworks stop being landing page generators and start being experience engines.
Commerce Engine gives those frameworks the primitives they need - not templates, not plugins, not coupled themes — just clean domain APIs that behave like modern software.
That’s why headless storefronts built on frameworks are not a trend - they are a return to architectural sanity.