Shopify Hydrogen vs Next.js Commerce: какую архитектуру выбрать для магазина в 2026

В headless-разработке на Shopify сейчас доминируют два React-подхода: Shopify Hydrogen - мнениеносный, нативный для Shopify фреймворк на Remix (React Router v7), который разворачивается исключительно на Oxygen (edge-платформе Shopify поверх Cloudflare Workers), и Next.js Commerce - композируемая референсная реализация Vercel на Next.js App Router с React Server Components, разворачиваемая на любом Node.js-хостинге.

Я сравниваю их по шести измерениям: модель рантайма и деплоя, устройство слоя данных, стратегия кеширования, полевые данные CrUX, опыт разработчика и полная стоимость владения вместе с риском вендор-локина. В конце - практический фреймворк выбора, привязанный к реальным ситуациям команд и бизнеса.

Часть I - Ландшафт headless-коммерции

Headless-подход отделяет фронтенд от коммерческого бэкенда - каталога, корзины, чекаута, остатков и данных покупателей. Фронтенд получает коммерческие примитивы через API, а не отрисовывает шаблоны, которыми управляет платформа.

Это разделение даёт два стратегических результата. Первый - полный инженерный контроль над производительностью и опытом пользователя, независимо от того, как рендерит сама коммерческая платформа. Второй - свобода собирать лучшее в своём классе: Algolia для поиска, Nosto для персонализации, Yotpo для отзывов, - не оглядываясь на встроенный набор функций платформы. Плата за это - инженерные затраты: в headless-фронтенде нужно явно реализовать то, что связанная витрина (Shopify Liquid, темы Magento) даёт по умолчанию.

Внутри headless-экосистемы Shopify сложились две школы. Hydrogen ставит на то, что глубокая нативная интеграция с API, аналитикой и B2B-примитивами Shopify даёт лучшую долгую продуктивность, если вы окончательно выбрали Shopify. Next.js Commerce ставит на то, что независимость от бэкенда и переносимость дают лучшую долгую гибкость, если ваша коммерческая стратегия ещё может измениться.

Главное, что нужно понимать сразу: оба фреймворка при корректной реализации укладываются в пороги «Good» по Core Web Vitals. Разрыв в производительности реален, но решающим фактором не является. Это стратегический архитектурный выбор про связанность, топологию деплоя и владение платформой вдолгую, а не про оптимизацию скорости.

Часть II - Архитектура Shopify Hydrogen

Техническая архитектура Hydrogen стоит на трёх спроектированных вместе опорах: прикладной фреймворк Remix (React Router v7), edge-рантайм Oxygen и набор первосторонних клиентов к API Shopify.

2.1 - Основание Remix: модель loader/action

Hydrogen 2.0 (общая доступность - январь 2024) заменил собственный React-фреймворк Hydrogen 1.x на Remix в качестве основания. Это решение объединило Hydrogen с более широкой экосистемой Remix и убрало самописные стриминговые примитивы в пользу обкатанной модели loader/action. Remix (с февраля 2025 - React Router v7) реализует серверо-центричный цикл запрос-ответ на двух основных конструкциях.

• Функции loader выполняются на сервере до рендера компонента маршрута. Они получают HTTP-запрос (включая параметры URL, куки и заголовки) и возвращают типизированные данные через ответ json() или defer(). Примитив defer() включает стриминг на Suspense: критичные данные резолвятся синхронно, а отложенные приходят параллельно и подставляются в границы Suspense по мере готовности промисов.
• Функции action обрабатывают запросы не-GET: отправки форм и мутации. Они выполняются на сервере, меняют состояние (добавить в корзину, изменить количество) и возвращают редирект или данные. Для большинства коммерческих взаимодействий это убирает клиентский паттерн fetch плюс синхронизация состояния.
• Вложенная маршрутизация позволяет загружать данные на уровне каждого маршрута: /products/:handle грузит данные товара независимо от данных коллекции родительского /products, и каждая граница показывает свой скелетон.

Модель Remix архитектурно ближе всего к классическому серверному вебу с циклом запрос-ответ. Существенно, что в Hydrogen нет аналога статической генерации: каждый маршрут либо рендерится динамически на Oxygen, либо отдаётся из CDN-кеша Cloudflare. Аналогов ISR (инкрементальной статической регенерации) и PPR (частичного пререндеринга) нет, и это заметно влияет на TTFB некешированных запросов.

2.2 - Oxygen: рантайм V8-изолятов на Cloudflare Workers

Oxygen - собственная edge-платформа Shopify, которая идёт без доплаты для всех развёртываний Hydrogen. Она построена на архитектуре V8-изолятов Cloudflare Workers, а это принципиально другая модель исполнения, чем у обычных serverless-функций.

• Холодный старт меньше миллисекунды: V8-изоляты делят процесс движка V8 с рантаймом Workers. Поднять новый изолят стоит менее 1 мс против 100–800 мс у холодного старта Node.js-лямбды. Это снимает штраф холодного старта, из-за которого обычный serverless плохо подходит для чувствительной к задержкам коммерции.
• Исполнение на глобальном крае сети: Oxygen автоматически разворачивается на все 300+ точек присутствия Cloudflare. Запрос страницы товара из Токио выполняется в Токио, а вызов Storefront API уходит на ближайший узел Shopify, часто размещённый в том же дата-центре Cloudflare.
• Ограничения рантайма: V8-изоляты работают только в рамках Web API. Встроенные модули Node.js (fs, path, crypto из стандартной библиотеки), нативные аддоны и порождение дочерних процессов недоступны. Это самая частая точка трения при переносе на Hydrogen утилитарных библиотек, написанных под Node.js.

2.3 - Набор нативных API-клиентов Shopify

Hydrogen поставляет типизированные клиенты первого класса ко всей поверхности API Shopify, и это заметное эргономическое преимущество перед ручным написанием GraphQL-запросов к Storefront API.

• Клиент Storefront API (createStorefrontClient): типизированный GraphQL-клиент со встроенной колокацией фрагментов, управлением кеш-тегами и автоматическими persisted queries (APQ). APQ превращает полные строки GraphQL-запросов в хеши SHA-256, сокращая полезную нагрузку запроса более чем на 90% и открывая кеширование в CDN по стабильному URL.
• Клиент Customer Account API (createCustomerAccountClient): поток OAuth 2.0 PKCE для headless-аутентификации покупателей. Заменяет устаревший подход с токенами Multipass, давая ограниченный по правам доступ к заказам, адресам, B2B-аккаунтам компаний и программам лояльности.
• Cart API: серверное управление корзиной с оптимистичными мутациями. Компонент <CartForm> отправляет данные через action Remix, что даёт работающую корзину вообще без JavaScript как базовый уровень прогрессивного улучшения.
• Аналитика (usePageAnalytics, useCartAnalytics): структурированные эмиттеры событий, совместимые с Shopify Analytics, Google Analytics 4 и Meta Pixel, - без сторонних тег-менеджеров и без отправки клиенту SDK аналитики.

Часть III - Архитектура Next.js Commerce

Next.js Commerce (референсная реализация vercel/commerce) построена на Next.js 15 App Router с React Server Components как основным архитектурным паттерном. Её базовый тезис: слой данных, то есть интеграция с API Shopify, должен быть заменяемым адаптером, а не несущей конструкцией.

3.1 - React Server Components как слой данных с нулевой ценой

В Next.js Commerce каждая страница товара, страница коллекции и страница результатов поиска - это дерево серверных компонентов. Данные запрашиваются на сервере через GraphQL Storefront API типизированной обёрткой над fetch. Никаких useEffect, никаких клиентских вызовов API и никакого управления состоянием загрузки для первичных данных: дерево компонентов рендерится, когда данные уже получены.

• Цена в бандле - ноль. Серверные компоненты не попадают в клиентский JavaScript. Компонент ProductPage, который получает данные товара, рисует картинки, проходит по селекторам вариантов и форматирует цены, отправляет в браузер ровно 0 байт.
• Композиция вместо соглашений. Запрос данных живёт рядом с компонентом, который их потребляет: async function ProductDetails({ handle }) сам получает свои данные, а не принимает их от loader уровня маршрута. Это убирает прокидывание пропсов и позволяет ставить границы Suspense на компонент, а не на маршрут.
• Параллельные запросы. Несколько поддеревьев RSC получают данные одновременно без всякой координации. Promise.all в модели рендеринга RSC подразумевается сам собой: <ProductImages>, <PriceBlock> и <InventoryStatus> отправляют свои GraphQL-запросы параллельно.

3.2 - Архитектура кеширования Next.js 15

Модель кеширования Next.js 15 вводит три отдельных слоя кеша, которые в коммерческих сценариях складываются друг с другом.

• Full Route Cache (слой CDN): готовый HTML-ответ страницы товара кешируется на Edge Network Vercel. При попадании в кеш TTFB составляет 15–40 мс независимо от сложности серверного рендера. Инвалидация идёт через revalidateTag('product-${handle}'), обычно по вебхуку Shopify при обновлении товара, который срабатывает через секунды после правки в админке.
• Data Cache (слой отдельных запросов): каждый вызов fetch() кешируется по ключу URL плюс опции запроса. fetch(endpoint, { next: { tags: ['shopify'], revalidate: 3600 } }) держит ответ Storefront API час и делит его между всеми параллельными серверными рендерами, убирая дублирующие вызовы API на всплесках трафика.
• Partial Prerendering (PPR): статическая оболочка страницы товара - лейаут, навигация, hero-картинка, название - пререндерится на сборке и кешируется в CDN с бесконечным TTL. Динамические части - остатки в реальном времени, персональные цены, рекомендации - стримятся с сервера по мере резолва границ Suspense. Браузер получает статическую оболочку с TTFB меньше 50 мс из CDN, а динамика приходит за 200–400 мс. Это ключевое преимущество Next.js Commerce перед Hydrogen на больших каталогах.

3.3 - Независимость от бэкенда: паттерн адаптера

Сильнее всего Next.js Commerce отличает от Hydrogen явная изоляция коммерческого слоя данных за типизированным интерфейсом адаптера. Все вызовы API Shopify инкапсулированы в lib/shopify/ - модуле, который экспортирует типизированные функции (getProduct, getCollection, createCart, addToCart), и ни один специфичный для Shopify тип не протекает в дерево компонентов.

Замена Shopify на Medusa (open source), BigCommerce или собственный API сводится к реализации того же интерфейса в lib/medusa/ и правке одного импорта: дерево React-компонентов остаётся нетронутым. Это не теоретическая возможность - в репозитории vercel/commerce живут пакеты провайдеров для Shopify, BigCommerce и Saleor, и каждый реализует один и тот же интерфейс.

Часть IV - Разбор бенчмарков производительности

Эмпирическое сравнение требует различать лабораторные метрики (Lighthouse, WebPageTest) и полевые (CrUX, 75-й перцентиль реальных пользователей). Лаборатория меряет одну идеальную загрузку; поле меряет распределение настоящего опыта по устройствам, сетям и географии. Для витрины рабочая метрика - p75 LCP из CrUX: именно она определяет прохождение Core Web Vitals в поиске Google.

• TTFB (p75, глобально): Hydrogen на Oxygen: 45–90 мс (edge-рендер в V8-изоляте, Storefront API рядом). Next.js Commerce на Vercel с PPR: 20–50 мс на кешированную статическую оболочку плюс 180–350 мс до первого динамического куска. Без PPR: 80–160 мс.
• LCP (p75, страница товара): Hydrogen: 1,2–1,9 с (hero-картинка предзагружена через <link rel=preload> в loader маршрута, edge-рендер на Oxygen). Next.js Commerce с PPR: 0,8–1,4 с (HTML статической оболочки закеширован в CDN, hero-картинка предзагружена в статическом <head>). Преимущество PPR сильнее всего заметно на мобильных в регионах с высокой задержкой.
• INP (p75): Hydrogen: 100–160 мс (база прогрессивного улучшения Remix, минимум клиентского JS на основные взаимодействия). Next.js Commerce: 80–140 мс (RSC снимает гидратацию неинтерактивных компонентов, уменьшая конкуренцию за главный поток во время обработки взаимодействия).
• CLS: У обоих фреймворков ниже 0,05, если у картинок явно проставлены width и height, а шрифты грузятся с font-display: swap. Автоматической защиты от сдвигов не даёт ни один: нужны корректные размеры изображений.
• Первичный JS-бандл (gzip): Hydrogen: примерно 180–210 КБ (рантайм Remix плюс утилиты Hydrogen плюс React). Next.js Commerce: примерно 110–145 КБ (рантайм Next.js, React и только интерактивные клиентские компоненты, без кода загрузки данных).

Разрыв в производительности между фреймворками реален, но для витрин с грамотно собранной инфраструктурой не решает. Оба при правильной настройке проходят пороги «Good» по Core Web Vitals (LCP ≤ 2,5 с, INP ≤ 200 мс, CLS ≤ 0,1) на полевых данных p75. Преимущество Next.js Commerce с PPR в 300–500 мс по LCP становится коммерчески значимым и заметно влияет на конверсию только на мобильных в Юго-Восточной Азии, Африке южнее Сахары и Латинской Америке, где медианная сетевая задержка превышает 150 мс.

Часть V - Опыт разработчика и экосистема

Опыт разработчика тут значит много: он прямо определяет, как быстро команда выкатывает и сколько умственных сил съедает поддержка.

• Hydrogen: Интеграция с Shopify CLI (shopify hydrogen dev) поднимает локальное окружение с живым доступом к Storefront API из тестового магазина. Встроенный режим мок-данных позволяет верстать интерфейс вообще без магазина. Возможности B2B Commerce - аккаунты компаний, объёмные цены, отсрочка платежа - здесь примитивы первого класса, а не самописные решения. Shopify Functions (серверная бизнес-логика для скидок и настройки платежей) нативно стыкуется с API-маршрутами Hydrogen.
• Next.js Commerce: Вся экосистема плагинов Next.js подключается без трения: next-auth для аутентификации покупателей, next-intl для локализации, Contentlayer для блога, Algolia для поиска. Vercel AI SDK 4.0 открывает AI-функции первого класса: чат-боты рекомендаций, семантический поиск и персонализированные лендинги как композируемые RSC-компоненты. Переносимость деплоя означает, что та же кодовая база работает на Vercel, AWS App Runner, Google Cloud Run или на своём Node.js-сервере.
• Ширина экосистемы: У Next.js экосистема значительно больше по любой метрике - загрузки npm, звёзды на GitHub, пакеты сообщества, сторонние интеграции. Экосистема Hydrogen уже, зато собрана под коммерцию: каждый пакет спроектирован под Shopify, и внутри этой области трения от интеграций почти нет.

Часть VI - Полная стоимость владения и риск локина

Дальше стоимости хостинга настоящий вопрос TCO - это упущенная выгода: риск миграции, потолок скорости добавления функций и доступность людей на рынке.

• Поверхность локина Hydrogen - рантайм Oxygen: Приложения Hydrogen рассчитаны на среду V8-изолятов Cloudflare Workers. Запуск Hydrogen на Node.js-сервере (AWS Lambda, Cloud Run) требует адаптера, который жертвует холодным стартом меньше миллисекунды и может потребовать полифиллов поверхности Web API. Путь задокументирован, но простым его не назвать.
• Поверхность локина Hydrogen - роутер Remix: Ментальная модель loader/action специфична для Remix. Переезд на другой фреймворк (Next.js App Router, Astro) требует переписать всю загрузку данных, обработку форм и логику навигации. Это не смена конфигурации, а существенный инженерный проект.
• Поверхность локина Hydrogen - клиенты API Shopify: createStorefrontClient, createCustomerAccountClient и CartForm - специфичные для Hydrogen абстракции над API Shopify. Если коммерческий бэкенд меняется - переезд на BigCommerce, собственный хостинг Medusa, - эти клиенты выбрасываются целиком, а вложения в нативные примитивы Shopify превращаются в технический долг.
• Поверхность локина Next.js Commerce: Основной локин - адаптер lib/shopify, но он изолирован явно и заменяем. Вторичный - PPR и инвалидация кеша по тегам у Vercel: точного эквивалента на самостоятельно развёрнутом Next.js нет (хотя revalidateTag работает где угодно, а вот PPR специфичен для Vercel). React и Next.js - стандартные отраслевые зависимости, а не привязка к проприетарной платформе.

• Стоимость хостинга: Hydrogen на Oxygen: 0 дополнительно, входит во все тарифы Shopify. Next.js Commerce на Vercel: Vercel Pro 20 долларов в месяц за проект плюс трафик на масштабе.
• Переезд на бэкенд не-Shopify: Hydrogen: очень высокий риск, переписывание фреймворка целиком. Next.js Commerce: низкий риск, замена адаптера за 2–5 инженерных дней.
• B2B Commerce из коробки: Hydrogen: есть, нативный Customer Account API с примитивами компаний и B2B. Next.js Commerce: требует своей реализации B2B-цен и управления аккаунтами.
• Контроль мультирегионального деплоя: Hydrogen: сеть Cloudflare, 300+ точек присутствия, автоматически. Next.js Commerce: Edge Network у Vercel (100+ точек на Pro, настраивается) либо своё управление.
• Доступность людей: Инженеров с Next.js на рынке найма заметно больше, чем с Hydrogen и Remix. Для растущих команд это нетривиальный фактор TCO.

Часть VII - Продакшен-свидетельства и кейсы

Лабораторные бенчмарки показывают только часть картины. Вот что на самом деле видно на продакшен-развёртываниях под нагрузкой.

• Gymshark (Hydrogen): Переезд Gymshark на Hydrogen (по опубликованным данным, третий квартал 2024) дал медианный TTFB 50 мс на страницах товаров по всему миру - в 2,1 раза лучше их прежней самописной реализации на Next.js. Ключевым фактором стало то, что edge-вычисления Oxygen оказались рядом со Storefront API внутри инфраструктуры Cloudflare, и межцентровая задержка прежней архитектуры исчезла.
• Allbirds (Hydrogen): Allbirds выбрали Hydrogen ради глубокой интеграции с Shopify Analytics, что позволило отказаться от самописного тег-менеджера. Уход тег-менеджера с критического пути дал улучшение LCP на 340 мс на мобильных.
• Patagonia (Next.js + Shopify): Реализация Patagonia показывает преимущество связки контента и коммерции: на страницах товаров у них редакционные данные об экологическом следе из Contentful, собранные вместе с данными Shopify в одном дереве RSC. Повторить это на Hydrogen можно через композицию loader'ов Remix, но получится многословнее, чем неявная серверная выборка в RSC.
• Демо Vercel Commerce (Next.js PPR): Собственное референсное развёртывание Vercel показывает LCP 0,7 с на Edge Network с PPR. Статическая оболочка страницы товара отдаётся из CDN за 28 мс TTFB, а динамические остатки и цены дострименваются за 220 мс. Это потолок производительности паттерна Next.js Commerce.

Часть VIII - Фреймворк принятия решения

Вот как соотнести вашу ситуацию с правильным выбором.

• Берите Shopify Hydrogen, когда: (1) Ваш коммерческий бэкенд - Shopify и останется Shopify на горизонте от трёх лет, без требований к мультиплатформенности. (2) Нужны нативные возможности B2B Commerce: аккаунты компаний, объёмные цены, отсрочка платежа, B2B-кабинет. (3) У команды есть экспертиза в Remix или готовность в неё вложиться. (4) Нужна глубокая интеграция с Shopify Analytics без тег-менеджера. (5) Edge-топология Cloudflare - жёсткое требование, географическое или договорное.
• Берите Next.js Commerce, когда: (1) Гибкость бэкенда стратегически важна: мультивендорность, возможный переезд платформы или собственный коммерческий бэкенд. (2) У команды уже есть экспертиза в Next.js и RSC. (3) Нужна связка контента и коммерции: блог, редакционные и локализованные материалы из CMS рядом с данными товаров. (4) Вы строите не только коммерцию: закрытые SaaS-функции, AI-персонализацию, инструменты сообщества. (5) Нужна переносимость деплоя: свой хостинг, мультиоблако или независимость от конкретного edge.

Эвристика, которая упрощает весь этот фреймворк: если ваша пятилетняя дорожная карта - только Shopify, берите Hydrogen; если в ней есть сколько-нибудь заметная вероятность смены бэкенда, берите Next.js Commerce. Разница в производительности обратного выбора не оправдывает: при должных инженерных вложениях оба фреймворка укладываются в одни и те же пороги Core Web Vitals.

Заключение

Hydrogen и Next.js Commerce - не просто две реализации одной идеи, а разные архитектурные ставки. Совместное проектирование Hydrogen с инфраструктурой Shopify - рантайм V8-изолятов Oxygen, нативные клиенты API, B2B и аналитика первого класса - делает его по-настоящему сильным для тех, кто окончательно выбрал Shopify: холодный старт меньше миллисекунды, вызовы API рядом, аналитика без настройки. Но за эту глубину платят реальной связанностью: с курсом платформы Shopify, с ментальной моделью Remix и с ограничениями рантайма Oxygen.

Ключевое решение Next.js Commerce - изолировать коммерческий бэкенд за типизированным адаптером - стоит вам части эргономики: взаимодействие с Shopify приходится расписывать явнее, чем через нативные клиенты Hydrogen. Взамен вы получаете архитектурную свободу: переносимость бэкенда, гибкость деплоя и всю экосистему Next.js вместе с PPR, AI SDK и RSC. Если вы строите платформу, которая может обслуживать несколько брендов, сменить бэкенд или вырасти за пределы чистой коммерции, эта свобода стоит лишней настройки.

Архитектурный консалтинг, скоупинг миграции на headless Shopify или внедрение Next.js Commerce - услуга фронтенд-архитектуры | кейсы | обсудить проект.

Частые вопросы

• Можно ли развернуть Hydrogen вне Oxygen? Да, с оговорками. Hydrogen даёт адаптер для Oxygen и адаптер для Node.js. Второй теряет холодный старт V8-изолята меньше миллисекунды и требует полифиллов Web API. Hydrogen на своём Node.js-сервере работает корректно, но характеристики Oxygen не повторяет.
• Работает ли Next.js Commerce с Shopify Checkout? Да. Shopify Checkout остаётся страницей на стороне Shopify в обоих фреймворках: ни Hydrogen, ни Next.js Commerce по умолчанию не делают свой интерфейс чекаута. Оба уводят на myshop.myshopify.com/checkout для оплаты. Кастомный чекаут через Checkout Extensibility одинаково работает с обоими.
• У какого фреймворка SEO из коробки лучше? Оба отдают краулеру полный HTML на первом запросе: Hydrogen через edge-рендер Remix, Next.js Commerce через SSR или PPR. Ни одному для индексации не нужен JavaScript. У Next.js Commerce есть небольшое преимущество в автоматизации мета-тегов через generateMetadata() и во внедрении разметки через JSON-LD-компоненты.
• Можно ли использовать Server Actions в Hydrogen? Нет. Server Actions - фича Next.js (и рекомендованный командой React примитив мутаций). Hydrogen использует функции action из Remix: семантически это эквивалент - отправка формы запускает серверную мутацию без клиентского fetch, - но реализовано иначе. Директива 'use server' в Hydrogen недоступна.
• Как быть с Shopify Markets для мультиязычности? У Hydrogen поддержка Shopify Markets первого класса через getStorefrontHeaders() и запросы к Storefront API с учётом локали. Next.js Commerce требует реализовать вызовы с учётом Markets вручную. Для витрин именно на Shopify Markets, а не на собственной стратегии локализации, Hydrogen из коробки даёт заметно лучшую мультирегиональность.

Источники

• Shopify. «Hydrogen Documentation» (2026)
• Shopify Engineering. «Hydrogen 2.0: Built on Remix» (2024)
• Shopify Engineering. «Gymshark Hydrogen Case Study» (2024)
• Vercel. «Next.js Commerce Reference Implementation»
• Remix / React Router. «React Router v7 Documentation» (2025)
• Cloudflare. «How Workers Works - V8 Isolate Architecture»
• Vercel. «Partial Prerendering in Next.js 15» (2025)
• Shopify. «Storefront API Reference» (2024-01)
• Shopify. «Customer Account API Documentation»
• Google. «Core Web Vitals - Understanding the Metrics»

Hydrogen против Next.js Commerce против production-темплейта

Если коротко: Hydrogen даёт нативную глубину Shopify, но привязывает к Oxygen и к Shopify; Next.js Commerce даёт композируемую переносимость, но приезжает как отправная точка, а не готовый магазин; production-темплейт даёт протестированную витрину под любой из этих бэкендов, живую за недели.

Что быстрее, Shopify Hydrogen или Next.js Commerce?

На полевых данных оба проходят пороги «Good» по Core Web Vitals, если собраны правильно, так что разрыв невелик и решающим не является. У Hydrogen небольшое преимущество на первой загрузке за счёт edge-рантайма Oxygen; Next.js Commerce догоняет его через React Server Components и грамотное кеширование. Выбирайте по локину и гибкости, а не по чистой скорости.

Есть ли готовое решение, чтобы не строить с нуля?

Да. Если вам близок подход Next.js Commerce, но собирать витрину с нуля не хочется, Headless Commerce Template - это продакшен-витрина композируемой архитектуры, которая работает на Shopify или Magento, приезжает с контентом, поиском, лояльностью и подарочными картами и проходит гейты доступности и производительности в CI. Вы подключаете свой бэкенд и выходите в прод за недели, а код остаётся вашим.