5 Open Source E-commerce платформ для разработчиков

Для frontend-инженеров, создающих headless-витрину в 2026 году, наиболее сильными open-source commerce-бэкендами для оценки являются Medusa, Saleor, Vendure, Sylius и Shopware. Каждая из них построена по принципу API-first, активно поддерживается и хорошо сочетается с витриной на Next.js или другом React-фреймворке — однако они существенно различаются по языковому рантайму, форме API (REST vs GraphQL), модели лицензирования и операционной нагрузке при самостоятельном хостинге. Эта статья поможет вам составить шорт-лист для проекта, в который вы готовы вложить недели интеграционной работы и годы поддержки.

WooCommerce, Magento и PrestaShop заслуживают честного упоминания: это зрелые, широко распространённые экосистемы с обширными маркетплейсами плагинов и инструментами для мерчантов, которые платформы из нашего списка пока не превзошли. Однако их центр притяжения — мир WordPress и admin-шаблонов, а не API-driven витрины на TypeScript. Если ваша витрина — это Next.js-приложение, обращающееся к типизированному SDK или GraphQL-эндпоинту, то пять платформ ниже и составляют актуальный шорт-лист. Если же ваша витрина — это тематический CMS-сайт, которым управляет маркетинговая команда, вы читаете не ту статью.

Headless commerce — это уже не тренд, который нужно продавать: это архитектура по умолчанию для новых витрин. Вопрос не в том, стоит ли отделять витрину от commerce-движка, а в том, какой движок обеспечит лучший developer experience на годы разработки фич вперёд.

Как выбрать: сравнительная таблица

Быстрее всего сузить шорт-лист позволяет сравнение платформ по параметрам, которые реально важны разработчику витрины. Таблица ниже суммирует пять кандидатов; количество звёзд и версии релизов постоянно меняются, поэтому воспринимайте их как отправную точку и проверяйте актуальные данные на странице GitHub releases каждого проекта перед принятием решения.

На двух столбцах стоит остановиться подробнее. Столбец лицензии не раскрывает всей картины: Vendure и Shopware поставляют MIT-лицензированное ядро, полностью пригодное для production, вместе с отдельно лицензируемыми коммерческими managed-платформами. Это важно учитывать при планировании бюджета, а не воспринимать как уловку — open-source ядро действительно можно использовать без оплаты платформенного тарифа. Столбец footprint при самохостинге отражает минимальный набор сервисов, которые вам придётся эксплуатировать в production, и именно здесь Saleor заметно отличается от Node-based вариантов.

Medusa — Node.js/TypeScript headless commerce с модулями и workflows v2

Medusa — это Node.js/TypeScript headless commerce-бэкенд, в котором релиз v2 перестроил платформу вокруг независимых commerce-модулей — products, cart, orders, inventory, pricing — каждый из которых можно заменить собственной реализацией или сторонним сервисом. Подробнее об архитектуре модулей и workflows см. в официальной документации v2.

Для frontend-инженера результат — наиболее компонуемая из пяти платформ. Код витрины обращается к Medusa-серверу через типизированный JavaScript-клиент; кастомизация бэкенда выполняется путём написания модулей и workflows на TypeScript, которые при желании живут в том же монорепозитории, что и остальные сервисы команды. Официальный Next.js-стартер из документации Medusa разворачивает рабочую витрину с корзиной, чекаутом и личным кабинетом одной командой create-medusa-app.

Сильные стороны Medusa:

• Сквозная типизация. Сервер — TypeScript, SDK для витрины — TypeScript, кастомные модули — TypeScript. Никакого шага codegen между схемами и типами витрины.
• Workflows. Medusa v2 предоставляет явный примитив workflow для многошаговых commerce-операций (оформление заказа, возврат и т. д.), что упрощает работу с длительными и компенсируемыми операциями по сравнению с неявными цепочками транзакций.
• Простая локальная разработка. Один Node-процесс поверх PostgreSQL плюс Redis для фоновых задач.

На что обратить внимание в Medusa:

• REST-first. Основной API Medusa — REST. Командам, которым нужен единый GraphQL-эндпоинт и codegen-driven типы, Saleor подойдёт лучше.
• Миграция v1 → v2. Кодовые базы на Medusa v1 требуют нетривиальной работы по миграции: система модулей, admin и API существенно изменились.

Выбирайте Medusa, если ваша команда работает на TypeScript, вы хотите полного контроля над кастомизацией на своём языке и вас устраивает эргономика REST + типизированный SDK. Пропустите Medusa, если вам нужен GraphQL-only слой данных или полноценный admin и инструменты мерчандайзинга «из коробки» с первого дня.

Saleor — GraphQL-first headless commerce на Python/Django

Saleor — это Python/Django headless commerce-платформа с GraphQL-first API. Каждая commerce-операция — запросы продуктов, мутации чекаута, управление заказами, аккаунты покупателей — проходит через единый версионированный GraphQL-эндпоинт, задокументированный в справочнике Saleor API. Кодовая база лицензирована под BSD-3-Clause; см. файл LICENSE на GitHub.

GraphQL-first подход наиболее ощутим на уровне витрины. Next.js-витрина может размещать требования к данным рядом с компонентами через urql, Apollo или graphql-request, запускать graphql-codegen против схемы Saleor и получать полностью типизированные query- и mutation-хуки без написания отдельного REST-адаптера. Типичный запрос страницы продукта выглядит так:

query ProductBySlug($slug: String!, $channel: String!) {
  product(slug: $slug, channel: $channel) {
    id
    name
    slug
    description
    variants {
      id
      name
      quantityAvailable
    }
  }
}

Этот единственный запрос возвращает ровно то, что рендерит страница — никакого overfetching, никаких отдельных вызовов инвентаря, никаких хелперов форматирования цены, которые расходятся с серверным представлением валюты. Saleor также публикует официальный пример Next.js-витрины (репозиторий storefront), который можно форкнуть вместо того, чтобы строить с нуля.

На что обратить внимание в Saleor:

• Операционный footprint. Для самостоятельного хостинга Saleor требует Python, PostgreSQL, Redis и Celery worker-процесс для асинхронных задач. Это тяжелее, чем связка Node + Postgres, и об этом стоит знать, если ваша команда не работает с Python-стеком.
• Дисциплина версионирования схемы. GraphQL-first платформа означает, что breaking-изменения схемы видны явно. Saleor выпускает новые минорные версии с чёткими инструкциями по миграции, но витрины, не фиксирующие схему и не перегенерирующие типы, столкнутся с незаметными поломками после обновлений.

Выбирайте Saleor, если вам нужен единый GraphQL-эндпоинт, вы готовы эксплуатировать Python-стек и ваша команда разработки витрины хорошо знакома с GraphQL-клиентами и codegen. Пропустите Saleor, если у вашей команды нет опыта эксплуатации Python и вы предпочитаете держать весь стек на Node.

Vendure — TypeScript/NestJS-фреймворк с MIT Core и коммерческим Platform-тиром

Vendure — это TypeScript/NestJS headless commerce-фреймворк с GraphQL API и Angular-based admin. Это единственная платформа в данном сравнении, которая поставляет plugin API, сервисный слой и расширения GraphQL-схемы на TypeScript с полным выводом типов — то есть кастомные плагины и код витрины разделяют единый язык и модель типов. Документация Vendure охватывает систему плагинов, двойные Shop/Admin GraphQL API и модель данных.

Open-source Core Vendure (MIT-лицензия) — это полнофункциональный headless commerce-движок. Коммерческая Vendure Platform добавляет managed-хостинг, enterprise-поддержку и дополнительные модули, но не является обязательной для запуска production-витрины. Это разграничение важно понять до принятия решения: Core действительно полноценен, и «open source» здесь не означает «демо с ограниченными возможностями».

С точки зрения витрины Vendure предоставляет два GraphQL API — Shop для публичных операций витрины и Admin для бэк-офисных инструментов. Оба поддерживают интроспекцию и удобны для codegen. В основе сервера лежит NestJS, поэтому кастомные плагины следуют привычному паттерну module-provider, если у вашей команды есть опыт с NestJS.

Сильные стороны Vendure:

• TypeScript везде. Сервер, плагины, расширения admin UI и витрина — единая система типов.
• Чистая архитектура плагинов. Кастомные поля, lifecycle-хуки и расширения GraphQL-схемы — полноправные механизмы, а не надстройки.
• Лёгкий самохостинг. Один Node-процесс поверх PostgreSQL или MySQL. По умолчанию для локальной разработки используется SQLite.

Компромиссы Vendure:

• Меньшая экосистема. По сравнению с Saleor или Medusa каталог сторонних плагинов и интеграций меньше. Придётся писать больше связующего кода самостоятельно.
• Admin на Angular. Если ваша команда планирует активно кастомизировать admin UI и работает исключительно с React, это создаёт дополнительный контекстный переключатель.

Выбирайте Vendure, если вам нужен максимально TypeScript-native и типобезопасный headless commerce-стек и вы готовы самостоятельно реализовывать часть интеграций. Пропустите Vendure, если вам нужен широкий маркетплейс плагинов с первого дня или вы не можете мириться с Angular-admin.

Sylius — Symfony commerce-фреймворк с REST и GraphQL через API Platform

Sylius — это open-source ecommerce-фреймворк на Symfony (PHP). Он позиционируется именно как фреймворк, а не готовая платформа: он предоставляет commerce-примитивы (продукты, каналы, заказы, промоакции, корзины) и предполагает, что вы самостоятельно скомпонуете из них приложение под нужды вашего бизнеса. Документация Sylius охватывает модель компонентов и Symfony-бандлы.

Для frontend-инженеров Sylius интересен своим API-слоем. Sylius интегрируется с API Platform для предоставления REST и GraphQL-эндпоинтов поверх своей модели данных, что делает его пригодным в качестве headless-бэкенда для Next.js или другой JavaScript-витрины. Витрина по умолчанию использует Twig-шаблоны — приемлемо для традиционных сборок, игнорируемо при headless-подходе.

Сильные стороны Sylius:

• Глубина Symfony. Если ваша организация хорошо знает Symfony, Sylius органично вписывается в более широкую PHP enterprise-экосистему лучше, чем любая другая платформа из этого списка.
• Кастомизация через идиомы фреймворка. Переопределяйте сервисы, события и сущности стандартными паттернами Symfony. Никакого проприетарного plugin DSL.
• MIT-лицензия, коммерческий тир не требуется. Полная кодовая база Sylius под MIT — это то, на чём вы строите.

Компромиссы Sylius:

• PHP-рантайм. Next.js-команда без опыта эксплуатации PHP наследует PHP-FPM, Composer и Symfony-инструментарий для бэкенда.
• Требует больше сборки. Sylius честно позиционирует себя как фреймворк. Для достижения функционального паритета с готовой платформой придётся написать больше кода, чем с Medusa или Saleor.

Выбирайте Sylius, если у вас есть внутренняя экспертиза в Symfony и вы хотите commerce-фреймворк, который можно полностью адаптировать под свою предметную область. Пропустите Sylius, если ваша команда работает только с JS и вы предпочитаете не запускать PHP-рантайм рядом с Node-сервисами.

Shopware 6 — PHP/Symfony-бэкенд с богатыми инструментами для мерчантов и Vue.js-витриной

MIT-лицензированный Community Edition Shopware 6 — это полнофункциональный commerce-бэкенд с поддержкой как традиционного, так и headless-развёртывания, предоставляющий REST Store API наряду с Vue.js-based фреймворком витрины. Коммерческие планы Rise, Evolve и Beyond добавляют managed-хостинг, расширенные B2B-возможности и enterprise-функции поддержки, однако open-source ядро пригодно для production без коммерческой лицензии. Документация для разработчиков Shopware охватывает Store API, Admin API и системы приложений/плагинов.

Shopware — наиболее функционально полная для мерчантов платформа в данном сравнении. CMS «Shopping Experiences» предоставляет drag-and-drop конструктор страниц для маркетинговых материалов; rule builder поддерживает динамическое ценообразование, правила доставки и промоакции без написания кода; admin-инструменты действительно глубоки. Для разработчика, создающего Next.js-витрину, Store API основан на REST и хорошо задокументирован; существуют community Next.js-стартеры, потребляющие его.

Сильные стороны Shopware:

• Merchant-инструменты «из коробки», которых нет ни у одной из developer-first платформ выше.
• Сильные позиции на европейском рынке с зрелой партнёрской экосистемой.
• Гибридный headless. Можно использовать Vue.js-витрину по умолчанию или перейти на полностью headless-режим через Store API.

Компромиссы Shopware:

• Операционный footprint PHP + Elasticsearch. Более тяжёлый самохостинг по сравнению с Node-вариантами.
• Система плагинов ориентирована на PHP. Кастомизация бэкенда — на PHP/Symfony, даже если ваша витрина на TypeScript.

Выбирайте Shopware, если вам нужны существенные merchant-функции «из коробки» и вы готовы эксплуатировать Symfony/PHP-стек. Пропустите Shopware, если ваша команда работает только с JS и вы предпочитаете более лёгкий, developer-first вариант вроде Medusa или Vendure.

Когда вместо этого стоит выбрать Spree

Если Shopware кажется слишком enterprise-ориентированным, а ваша команда имеет опыт с Ruby on Rails, Spree Commerce — разумная альтернатива. Он лицензирован под MIT, полностью API-driven, поддерживает multi-store и multi-vendor конфигурации и существует достаточно давно, чтобы Rails-паттерны были хорошо устоявшимися. Компромисс аналогичен Sylius: Ruby on Rails вместо Symfony, но та же форма решения — принять экосистему зрелого серверного фреймворка в обмен на не-JS рантайм.

Факторы принятия решения на стороне frontend

На уровне интеграции витрины пять факторов определяют, будет ли бэкенд продуктивным или болезненным: эргономика TypeScript, совместимость с Next.js, холодный старт при локальной разработке, архитектура плагинов и глубина документации.

TypeScript и эргономика codegen. Medusa и Vendure поставляют TypeScript SDK, согласованные с типами сервера без отдельного шага генерации. GraphQL-схема Saleor лучше всего потребляется через graphql-codegen, что добавляет шаг сборки, но даёт отличные типизированные хуки. Sylius и Shopware требуют самостоятельного моделирования ответов API или использования community-generated клиентов.

Совместимость с Next.js. Medusa и Saleor поддерживают официальные примеры Next.js-витрин, работающие с App Router. У Vendure есть community-стартеры. Sylius и Shopware, как правило, потребляются Next.js-витринами через прямые API-вызовы или community SDK — это работает, но вам придётся писать больше интеграционного кода самостоятельно.

Опыт локальной разработки. Medusa и Vendure предлагают самый быстрый холодный старт — установить зависимости, запустить миграцию, стартовать сервер, готово. Saleor хорошо задокументирован, но тяжелее из-за требований Python + Redis + Celery; рекомендуется Docker Compose. Shopware и Sylius предполагают наличие рабочего PHP-окружения; Docker-образы упрощают это, но движущихся частей больше.

Архитектура плагинов и расширений. Все пять платформ поддерживают кастомные расширения, но developer experience различается. Плагины Vendure — это TypeScript-модули с типобезопасными lifecycle-хуками. Модули Medusa v2 — TypeScript-классы с чётким контрактом. Saleor использует webhook-based «apps», работающие как отдельные сервисы — более строгая граница изоляции, но большие операционные накладные расходы. Sylius и Shopware используют системы бандлов/плагинов Symfony.

Качество документации. Среди пяти платформ Medusa, Saleor, Vendure и Shopware поддерживают сайты с документацией, включающие справочники API, туториалы и обзоры архитектуры, достаточно актуальные относительно релизов. Документация Sylius обширна, но предполагает знакомство с Symfony.

Реальные сбои, которые случаются независимо от выбора платформы

Распространённый сценарий production-сбоя в headless-витринах — на любом бэкенде из этой статьи — это React hydration mismatch на страницах продуктов, когда серверно-отрендеренные цены, остатки на складе или локализованные строки расходятся с тем, что клиент рендерит после получения свежих данных. Другие повторяющиеся паттерны: незаметное расхождение состояния корзины, когда клиентская корзина и серверная сессия расходятся после сетевого сбоя; скрипты платёжных провайдеров (Stripe, Adyen, PayPal), не загружающиеся или не инициализирующиеся и проявляющиеся лишь как зависшая кнопка чекаута; breaking-изменения схемы после обновления бэкенда, порождающие загадочные null-поля вместо явных ошибок.

Эти сбои не зависят от платформы, но различаются по отлаживаемости в зависимости от того, как бэкенд предоставляет контекст ошибок в ответах API. GraphQL-ошибки Saleor содержат структурированные коды; REST-ответы Medusa включают типы ошибок; Shopware и Sylius используют структурированный формат ошибок Symfony. Независимо от вашего выбора, инструментирование витрины инструментами записи сессий, такими как OpenReplay — для захвата реального состояния DOM, сетевых запросов, ошибок консоли и действий пользователя, приведших к сбою корзины или чекаута — закрывает разрыв между «пользователь говорит, что чекаут не работает» и воспроизводимым баг-репортом. Продукт session-replay от OpenReplay создан специально для этой категории отладки frontend в production.

Принятие решения

Шорт-лист быстро сужается, как только вы взвешиваете языковую экспертизу команды и предпочтения по слою данных витрины. TypeScript-native команда, создающая Next.js-витрину с типизированным SDK, должна в первую очередь оценить Medusa, во вторую — Vendure. Команда, желающая единый GraphQL-эндпоинт и готовая эксплуатировать Python-стек, должна оценить Saleor. Symfony-fluent команда должна оценить Sylius для фреймворк-ориентированной сборки или Shopware для наиболее полного набора merchant-инструментов. Запустите локальный quickstart для одного-двух лучших кандидатов перед принятием решения — один день с docker-compose up и знакомством с admin расскажет вам больше, чем ещё одна неделя сравнительного чтения.

FAQ

Gain Debugging Superpowers

Unleash the power of session replay to reproduce bugs, track slowdowns and uncover frustrations in your app. Get complete visibility into your frontend with OpenReplay — the most advanced open-source session replay tool for developers. Check our GitHub repo and join the thousands of developers in our community.