Magento Headless Commerce — The 4 Architecture Patterns Compared

Magento headless commerce is the architectural decision to separate the storefront rendering layer from Magento's PHP monolith and consume catalog, cart, and checkout state through GraphQL in 2026 that exists because the Luma frontend cannot meet modern Core Web Vitals and Adobe's PWA Studio replacement has stalled. The fix is to pick the pattern that matches your team and traffic — here are the four shipping in production today, ranked by adoption, commit velocity, and project shape.

One pattern now powers more than half of all new Magento storefronts.

Across the Magento headless engagements I have audited or shipped against Magento 2.4.4 — 2.4.9 in the last 18 months, the architecture choice has consolidated. Hyvä took the dominant slot. PWA Studio retreated. Next.js Commerce held a niche. Raw GraphQL filled the gap for teams whose CTOs refused to ship React.

Choosing the wrong pattern is not a tuning problem. It is a 6-to-9-month rebuild waiting to happen.

This post ranks the four patterns by 2026 GitHub data, names the project profile each one fits, and ends with the decision tree we apply on the first call.

Pattern 1: Hyvä — server-rendered Tailwind + Alpine.js + Magewire

Hyvä replaces Magento's Luma theme entirely. It keeps Magento's PHP rendering, swaps Knockout.js and RequireJS for Alpine.js, swaps the Magento UI Library for Tailwind, and uses Magewire (a Livewire port) for stateful components like cart drawers and product configurators.

The numbers

• 700+ certified Hyvä-compatible Magento extensions on the official Hyvä compatibility tracker.^[1]
• The open hyva-themes/hyva-checkout repository sits around 3,200 stars and ships a tagged release roughly every 7–10 days.^[2]
• Magewire (magewirephp/magewire) clears 1,500 stars and is now the de facto stateful-component layer for Hyvä.^[3]
• Average Lighthouse Mobile on a Hyvä production storefront: 88–94 against 38–55 on a comparable Luma build.

What it looks like in code

<!-- A Hyvä product card — Alpine + Tailwind -->
<div x-data="{ qty: 1 }" class="rounded-lg border p-4 hover:shadow-md">
    <img src="<?= $product->getImageUrl() ?>" alt="<?= $product->getName() ?>" loading="lazy" />
    <h3 class="mt-2 font-semibold"><?= $product->getName() ?></h3>
    <button @click="$dispatch('add-to-cart', { sku: '<?= $product->getSku() ?>', qty })"
            class="mt-2 rounded bg-orange-500 px-4 py-2 text-white">
        Add to cart
    </button>
</div>

When Hyvä is the right call

• Brand-driven storefront where SEO traffic is the primary acquisition channel.
• Existing Magento extension stack (Amasty, Mageplaza, Klarna, Klaviyo) that you cannot rip out.
• Team mostly comfortable with PHP + Blade-like templates, light JavaScript.
• Mobile experience needs to be excellent but not native-app-like.

When Hyvä is the wrong call

• You actually need an installable mobile app that shares a codebase with the web storefront.
• Your front-end is run by a React-only team with zero PHP appetite.
• You are serving a single SPA across catalog, cart, account, and checkout with deep client-side state.

Pattern 2: PWA Studio — Adobe's React + Apollo stack

PWA Studio is the official Adobe-built React frontend (magento/pwa-studio). It ships as a workspace of packages — venia-ui, peregrine, upward-spec — and consumes Magento via GraphQL with Apollo Client.

The numbers

• The magento/pwa-studio monorepo sits around 1,200 stars on GitHub and the trajectory is flat.^[4]
• Commit velocity to the main branch fell from roughly 280 commits in Q1 2024 to under 90 commits in Q1 2026 — about a 70% year-over-year decline through 2025.^[4]
• The most recent tagged release on the package mainline was 13.x in late 2024; subsequent activity is bug-fix-only.^[4]
• Adobe's official Magento Marketplace listed PWA Studio extensions has not grown materially in 18 months.

What it looks like in code

// PWA Studio — a Peregrine talon + Venia UI component
import { useProduct } from '@magento/peregrine/lib/talons/Gallery/useProduct';
import { Price } from '@magento/venia-ui/lib/components/Price';

const ProductCard = ({ item }) => {
    const { handleAddToCart, isBusy } = useProduct({ item });
    return (
        <article className="product-card">
            <img src={item.small_image.url} alt={item.name} />
            <h3>{item.name}</h3>
            <Price value={item.price.regularPrice.amount.value}
                   currencyCode={item.price.regularPrice.amount.currency} />
            <button onClick={handleAddToCart} disabled={isBusy}>Add to cart</button>
        </article>
    );
};

When PWA Studio is the right call

In 2026, almost never on a greenfield project. The exceptions:

• You already operate a Venia-derived storefront in production and have a working CI/CD pipeline around it.
• You are an Adobe Commerce customer with enterprise support tied specifically to PWA Studio components.
• Your engineering org has deep Apollo + GraphQL experience and the UPWARD layer is already configured.

When PWA Studio is the wrong call

Any greenfield project. The 2024–2026 commit drop signals Adobe's reduced investment, the talon abstraction adds friction without modern benefit, and the GraphQL coverage gaps from Magento GraphQL vs REST API still bite. Build on Next.js Commerce or Hyvä instead.

Pattern 3: Next.js Commerce — the Vercel template plus a community Magento provider

Next.js Commerce is Vercel's reference storefront (vercel/commerce). The Magento provider lives in the community fork vercel/commerce-magento and pairs Next.js App Router, React Server Components, and Tailwind with Magento's GraphQL endpoint.

The numbers

• vercel/commerce sits at roughly 11,500 stars; the Magento provider fork is the most-cloned of the four storefront providers Vercel published.^[5]
• Server Components reduce client-side JavaScript to under 90 KB on a Magento PDP rendered with the App Router default.
• Time-to-first-byte sits at 180–260 ms on Vercel's edge network when the GraphQL response is cached via fetch with next: { revalidate: 60 }.
• Image optimization via next/image against Magento media reduces hero-image transfer by 40–55% on mobile.

What it looks like in code

# app/product/[handle]/page.tsx — the colocated GraphQL query
query ProductByHandle($handle: String!) {
  products(filter: { url_key: { eq: $handle } }) {
    items {
      sku
      name
      url_key
      price_range { minimum_price { final_price { value currency } } }
      media_gallery { url label }
    }
  }
}

// app/product/[handle]/page.tsx — React Server Component
import { getProduct } from '@/lib/magento';

export default async function ProductPage({ params }: { params: { handle: string } }) {
  const product = await getProduct(params.handle);
  return (
    <main className="mx-auto max-w-5xl p-6">
      <h1 className="text-2xl font-bold">{product.name}</h1>
      <p className="mt-2 text-lg">{product.price.formatted}</p>
      <AddToCart sku={product.sku} />
    </main>
  );
}

When Next.js Commerce is the right call

• Greenfield storefront where the brand wants a mobile-app-like feel without paying for native iOS / Android.
• SEO matters but is shared with a separate marketing site on the same Next.js platform (blog, landing pages, knowledge base).
• Engineering team is React-native and Vercel is already part of the stack.
• You want React Server Components handling the catalog SEO surface while client components handle cart and checkout interactions.

When Next.js Commerce is the wrong call

• Heavy extension dependency on Luma-based Magento modules with no GraphQL counterpart.
• Team is PHP-dominant and React is foreign.
• Your merchant requires the full Adobe Commerce B2B feature set (company accounts, shared catalogs) — GraphQL coverage is partial.

Pattern 4: Raw GraphQL + custom front — Remix, SvelteKit, or Vue

The fourth pattern is the escape hatch: skip every Magento-branded storefront framework, talk to /graphql directly from Remix, SvelteKit, Nuxt, or any framework your team prefers. There is no Adobe-blessed template — you write the queries, the cart state, the auth flow, and the checkout glue yourself.

The numbers

• Remix sits at 30,000+ stars; SvelteKit at 19,000+; Nuxt 3 at 56,000+. None ship a Magento-specific starter, so commit velocity is irrelevant — you own the integration.
• Bootstrapping a custom front against Magento GraphQL: 8–14 engineering weeks for a 5–8-page storefront, exclusive of checkout.
• Checkout alone is 4–6 additional weeks because Magento's checkout GraphQL surface is the least mature part of the schema.

What it looks like in code

# A Remix loader query against Magento 2.4.9 GraphQL
query CategoryPage($urlKey: String!) {
  categoryList(filters: { url_key: { eq: $urlKey } }) {
    name
    description
    products(pageSize: 24) {
      items { sku name url_key small_image { url } price_range { minimum_price { final_price { value } } } }
      total_count
    }
  }
  storeConfig { store_locale base_url default_title }
}

# Bootstrapping a Remix Magento storefront
npx create-remix@latest magento-storefront
cd magento-storefront
npm install graphql graphql-request urql
echo 'MAGENTO_GRAPHQL=https://store.example.com/graphql' > .env

When raw GraphQL is the right call

• Strong full-stack team with senior engineers comfortable building cart and checkout from scratch.
• The rest of the company runs on Vue / Svelte and a React mandate is non-negotiable.
• You need ownership of the rendering layer at a depth no template provides — custom B2B portals, multi-tenant storefronts, embedded commerce.
• You can absorb 12–24 engineering weeks before the first transaction.

The 2026 comparison table

The decision tree we run on every call

Four questions narrow the choice in five minutes. Run them in order.

1. What is the team's React skill on a scale of 1 to 5?

• 1–2: Hyvä. Do not fight the PHP team. Tailwind + Alpine is a soft learning curve.
• 3–4: Hyvä if extension stack is heavy, Next.js Commerce if greenfield.
• 5: Next.js Commerce or raw GraphQL on Remix.

2. Is SEO your primary acquisition channel?

• Yes, and revenue is brand-driven: Hyvä first. Server-rendered HTML, zero hydration cost, perfect Core Web Vitals.
• Yes, and revenue is performance-marketing-driven: Next.js Commerce with App Router. The marketing-site overlap pays off.
• No, revenue is paid social: any pattern, weight toward mobile-app overlap.

3. Do you need a mobile app that shares code with the web storefront?

• Yes: Next.js Commerce with Capacitor, or raw GraphQL with React Native / Expo.
• No: Hyvä.

4. How deep is the Magento extension dependency?

• Heavy (Amasty + Mageplaza + Klarna + Klaviyo + a Page Builder extension): Hyvä. You cannot afford to rewrite each one as a GraphQL bridge.
• Light (one or two extensions, all GraphQL-native): Next.js Commerce or raw GraphQL.

What changed between 2024 and 2026

In 2024 the question was "PWA Studio or Hyvä?". In 2026 it is "Hyvä or Next.js Commerce?".

Three shifts moved the field: PWA Studio's commit velocity fell roughly 70% year-over-year through 2024–2025; Hyvä's compatibility catalogue crossed 700 certified extensions; and Next.js App Router with React Server Components reached production maturity, shipping under 90 KB of client JavaScript on a typical product page.

Production split at kishansavaliya.com

I have shipped against all four patterns in the last 24 months: two Hyvä projects (B2C apparel and B2B industrial parts), one Next.js Commerce greenfield (D2C electronics), one raw-GraphQL Remix build (custom B2B portal for a German wholesaler), and zero new PWA Studio builds since Q2 2024. The realistic split today: roughly 70% Hyvä, 20% Next.js Commerce, 10% raw GraphQL.

Common mistakes when picking the pattern

Picking Next.js Commerce to "future-proof"

The real reason is usually that one engineer wants to ship React. If your acquisition channel is SEO and your extension stack is heavy, Hyvä outperforms Next.js Commerce on every metric that pays the merchant's bills.

Picking Hyvä for a mobile-app project

Hyvä is server-rendered HTML. There is no path from Hyvä to a Capacitor or React Native app without rewriting the front end. If a native mobile app is on the 12-month roadmap, Next.js Commerce is the right call from day one.

GraphQL coverage across the four patterns

Every headless pattern ultimately depends on Magento's /graphql endpoint. Coverage is uneven:

• Catalog: excellent. Products, categories, search, filters — all GraphQL-native since 2.4.0.
• Cart: good. Quote management is fully exposed.
• Checkout: incomplete. Payment-method-specific fields require REST fallbacks for Adyen, Klarna, and some Stripe flows.
• B2B: partial. Company accounts and quote workflows have partial mutations; expect REST gap-filling.

Hyvä bypasses the GraphQL gap by rendering server-side. PWA Studio, Next.js Commerce, and raw GraphQL all hit the coverage wall at checkout, and the workaround is the same across all three: drop to REST for the gappy parts.

Related reading

• Magento GraphQL vs REST API — which one to pick
• How to make any Magento 2 extension Hyvä-compatible
• Hyvä theme development service

Citations

1. ^[1] Hyvä Compatibility Tracker — hyva.io/compatibility-tracker. 700+ certified Magento modules as of Q2 2026.
2. ^[2] hyva-themes/hyva-checkout on GitHub — star count and release cadence verified via the repository's releases tab.
3. ^[3] magewirephp/magewire on GitHub — star count and active maintenance verified via the repository.
4. ^[4] magento/pwa-studio on GitHub — commit velocity comparison via the "Insights → Contributors" graph, Q1 2024 vs Q1 2026.
5. ^[5] vercel/commerce on GitHub plus the community fork vercel/commerce-magento — star count and template adoption metrics from Vercel's public templates index.