Sylius против Medusa: чей стек дороже поддерживать через три года

MAATRIX

Выбор между Sylius и Medusa почти всегда делают по вопросу «что проще поднять за выходные» — и это неправильный вопрос. Обе платформы можно развернуть на VPS за один вечер, обе бесплатны и открыты, обе честно решают задачу headless-коммерса. Разница, которая реально бьёт по бюджету, проявляется не в первую неделю, а через год-два эксплуатации: кто быстрее находит разработчика на замену, что ломается при обновлении мажорной версии и сколько кастомного кода превращается в балласт, который никто не хочет трогать. Ниже — сравнение с этой стороны, без «выбирайте по вкусу» в конце.

Два разных инженерных мира

Sylius — это PHP-платформа поверх Symfony: она не изобретает свою архитектуру, а честно наследует всё, что Symfony накопил за годы — контейнер зависимостей, компонентную систему, Doctrine ORM, консоль команд, систему событий. Доменная модель e-commerce (заказы, продукты, варианты, каналы продаж, зоны доставки) описана строго и явно, с расчётом на то, что бизнес-логику будете переопределять через официальные точки расширения — resource-слой, обработчики событий, декораторы сервисов. Это классическая enterprise-архитектура: многословная, местами избыточная для маленького магазина, но предсказуемая для тех, кто уже работал с Symfony.

Medusa — headless-коммерс на Node.js и TypeScript. С версии 2.x ядро официально называется modular monolith: заказы, корзины, ценообразование, регионы, склад собраны из отдельных модулей с чёткими границами, которые в теории можно заменять или отключать. Хранилище — PostgreSQL, для очередей и кеша нужен Redis. Фронтенд не идёт в комплекте — обычно берут Next.js Storefront из стартер-кита либо пишут свою витрину поверх JS/TS SDK или REST API. DX здесь заметно легче, чем у Sylius: меньше конфигурации, современный тулинг, привычные для фронтенд-разработчика паттерны.

Уже на этом шаге закладывается разная траектория поддержки: Sylius тянет за собой всю зрелость и всю тяжеловесность Symfony-экосистемы, Medusa — гибкость и нестабильность более молодой платформы, которая всё ещё меняет форму на уровне архитектуры.

Зрелость экосистемы: плагины, аддоны, готовые интеграции

Symfony как платформа существует больше десяти лет, и вокруг неё сложилась одна из самых зрелых PHP-экосистем: bundle-система стандартизирована, конвенции по структуре кода устоялись, большинство типовых задач (очереди через Symfony Messenger, кеширование, интеграция с внешними API) решаются проверенными компонентами, а не самописными велосипедами. У Sylius есть собственная экосистема плагинов (платёжные шлюзы через Payum, интеграции с PIM, ERP, поисковыми системами), но она заметно уже, чем у Magento в его лучшие годы — часть интеграций приходится дописывать вручную поверх официальных точек расширения. Плюс в том, что «дописать вручную» на Symfony — предсказуемая, документированная задача, а не археология по чужому недокументированному коду.

Medusa моложе как платформа, и переход на модульную архитектуру во 2-й версии фактически перезапустил экосистему плагинов: часть модулей и интеграций, написанных под первую версию, для второй пришлось переписывать заново, авторы обновляют их с разной скоростью. Официальные модули (платежи, поиск, файловое хранилище) поддерживаются активно, но сторонние плагины на практике нужно проверять на актуальность перед тем, как закладывать их в архитектуру — риск наткнуться на заброшенный репозиторий выше, чем в зрелой Symfony-экосистеме. При этом сам npm-мир вокруг Node.js огромен, и многое из недостающего можно закрыть общими JS-библиотеками, не завязанными на Medusa напрямую — это компенсирует часть разрыва, но требует больше самостоятельной интеграционной работы от команды.

Рынок труда: кого реально можно нанять через три года

Это, пожалуй, самый недооценённый фактор при выборе стека. Через три года исходная команда почти наверняка изменится хотя бы частично — кто-то уйдёт, придётся расширяться или передавать проект на аутсорс. Вопрос в том, сколько будет стоить и сколько времени займёт найти человека, который сможет разобраться в чужом коде без полугода погружения.

PHP и Symfony — стек с большим количеством опытных разработчиков на рынке, особенно в русскоязычном сегменте: Symfony долго был (и остаётся) стандартом для среднего и крупного enterprise-разработки в вебе, поэтому разработчиков, которые понимают DI-контейнер, Doctrine и событийную модель, найти проще, чем узких специалистов именно по Sylius. Специфика Sylius поверх общего Symfony-опыта осваивается за недели, а не месяцы — сама доменная модель e-commerce описана в документации достаточно подробно.

Node.js и TypeScript — сегодня один из самых массовых стеков среди фронтенд- и full-stack разработчиков в принципе, так что общий пул кандидатов огромен. Но именно опыт с Medusa — куда более узкая ниша: это не «просто Node-приложение», а платформа со своей модульной архитектурой, своими паттернами workflow-движка и своими нюансами миграций между версиями. Найти джуна или мидла, который писал на Node, — просто. Найти того, кто уже разбирался в устройстве Medusa изнутри, — заметно сложнее, и это ощутимо увеличивает время на онбординг нового человека в проект.

Итог этого раздела не в пользу одного стека железно — он в пользу того, что у Sylius ниже риск застрять без специалиста, а у Medusa ниже стоимость найма «в среднем», но выше стоимость адаптации конкретного разработчика под конкретный проект.

Стабильность API при обновлениях — где реально копится боль

Это ключевой пункт, если считать стоимость поддержки именно на трёхлетнем горизонте, а не в моменте запуска.

Symfony (а значит, и Sylius) исторически придерживается дисциплинированной модели устаревания: новая функциональность помечается как deprecated заранее, для каждого крупного обновления публикуется файл с построчным списком изменений, и переход между минорными версиями обычно не требует переписывания бизнес-логики — только правки по конкретным предупреждениям. Мажорные обновления Symfony (а вслед за ней и Sylius) случаются реже и обычно сопровождаются инструментами автоматизации миграции (rector-правила, скрипты для типовых замен). Это не значит «обновления бесплатны» — глубоко кастомизированный проект с множеством переопределённых сервисов всё равно потребует ручной проверки, — но сам процесс предсказуем и укладывается в оценку по часам почти всегда.

У Medusa другая история: переход с первой версии на вторую был не косметическим обновлением, а архитектурным переписыванием ядра — модульная система, новый способ описания workflow, изменённая структура админки и API. Для магазинов, построенных на первой версии, это означало не «обновить зависимости», а по сути смигрировать проект на новую платформу с переносом кастомных модулей и переработкой интеграций. Такие разрывы — не единичный случай, свойственный только Medusa, это обычная плата за молодость и активное развитие платформы: архитектура ещё ищет финальную форму, и следующий крупный виток изменений исключать нельзя. Для бизнеса это означает риск, который нужно закладывать в бюджет заранее, а не обнаруживать постфактум, когда апдейт становится обязательным из-за прекращения поддержки старой ветки.

Технический долг, который реально накапливается в обоих случаях

В Sylius технический долг чаще всего growing pain от глубокой кастомизации через официальные точки расширения. Чем больше сущностей Doctrine переопределено, чем больше сервисов задекорировано цепочкой из трёх-четырёх слоёв, тем сложнее новому человеку понять, где реально живёт логика — она формально «правильно» разложена по паттернам Symfony, но фактически размазана по десятку файлов. Плюс сама Doctrine ORM на больших каталогах и сложных выборках требует отдельного внимания к N+1-запросам и индексам — это не баг платформы, а обычная плата за ORM поверх реляционной модели, которая в других PHP-стеках проявляется точно так же.

В Medusa технический долг чаще копится на стороне кастомных модулей и воркфлоу-логики, написанной под конкретный проект без учёта того, что она может не пережить следующее мажорное обновление. Вторая типичная проблема — плагины и интеграции разного качества: если команда тянула в проект несколько сторонних модулей для расширения функциональности, а поддержка одного из них позже остановилась, приходится либо форкать его самостоятельно, либо переписывать функциональность на официальных модулях. Плюс сама разница между Node-процессом и окружением — TypeScript даёт статическую типизацию, но не спасает от архитектурных решений, принятых на скорую руку в начале проекта, когда команда торопилась в MVP.

Общий вывод здесь честный: технический долг накапливается в любой платформе, если проект живёт и растёт. Разница в том, какой именно долг вы получаете — предсказуемый и локализуемый (Sylius) или менее предсказуемый, но потенциально более крупный разовыми порциями при смене архитектуры (Medusa).

Как посчитать TCO для своего случая

Прежде чем выбирать стек по абстрактному сравнению, стоит прогнать оба варианта через один и тот же чек-лист применительно к вашей команде:

1. Кто уже есть в команде. Если у вас штатные PHP/Symfony-разработчики — переход на Medusa означает найм новых людей или переобучение текущих, и наоборот. Стоимость смены стека почти всегда выше, чем разница между самими платформами.
2. Сколько будет кастомизации. Стандартный каталог, стандартные способы оплаты и доставки — разница между стеками для поддержки минимальна. Много нестандартной бизнес-логики, интеграций с внешними ERP или маркетплейсами — заметнее выигрывает та платформа, где точки расширения понятнее вашей команде уже сейчас.
3. Готовность резервировать бюджет на мажорные обновления. У Sylius это плановые, предсказуемые работы. У Medusa стоит заранее закладывать сценарий «в какой-то момент понадобится полноценная миграция», а не обновление в один клик.
4. Требования к серверу и инфраструктуре. Оба стека PostgreSQL-центричны и требуют Redis для кеша/очередей — по железу разница не радикальная, но у Medusa процесс на Node.js обычно легче стартует на скромном VPS, тогда как Sylius на PHP-FPM с Symfony-контейнером требует более внимательной настройки OPcache и пула воркеров под нагрузку. Отдельно стоит прикинуть память под каждый стек заранее, а не по факту нехватки — этот расчёт разобран в статье про сколько RAM нужно для Medusa.
5. Горизонт планирования самого бизнеса. Если магазин точно проживёт три-пять лет и будет расти, дисциплинированная модель обновлений Symfony снижает риск дорогого сюрприза. Если это эксперимент на год-два, гибкость и скорость разработки на Medusa может окупить архитектурный риск — его вы просто не успеете почувствовать.

Полезно смотреть на этот выбор и шире — не только по конкретной платформе, а по общей логике накопления технического долга в инфраструктуре: когда разовая заплатка становится дороже полноценного решения. Этот фрейм разобран отдельно в статье про технический долг инфраструктуры, и он применим к обеим e-commerce платформам один в один.

Ещё один риск, который стоит проговорить на старте, а не через два года: что произойдёт, если человек, который поднимал и настраивал магазин, уйдёт из команды. Для Sylius на Symfony новому разработчику будет проще восстановить картину по стандартным конвенциям фреймворка, для сильно кастомизированной Medusa-инсталляции — сложнее, если документация внутри проекта велась не аккуратно. Как в принципе действовать в такой ситуации, независимо от стека, описано в статье ушёл ключевой разработчик — что крутится на серверах.

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