Когда у магазина появляются не только товары, но и история вокруг них — посадочные страницы, новости, промо-блоки, навигация, медиа и сезонные кампании, — складывать всё это в commerce backend быстро становится неудобно. В MedusaStore эту часть берёт на себя Payload CMS.
Payload CMS здесь — не замена Medusa backend и не место, куда нужно складывать всю правду о магазине. Его роль проще и точнее: content/admin слой для страниц, постов, медиа, навигации, footer, site settings и маркетинговых кампаний.
Такое разделение делает проект устойчивее и понятнее для людей, которые с ним работают. Commerce-сущности остаются в Medusa, контент живёт в Payload, витрина собирает пользовательский опыт поверх обоих источников, а staging runtime проверяет, что эти части действительно работают вместе. Главная мысль простая: CMS должна помогать рассказывать о магазине и управлять редакционными сценариями, но не должна забирать на себя роль commerce-ядра.
Коллекции и globals
Payload построен на Payload 3.83.0, Next.js 15.3.9 и PostgreSQL adapter. Основные коллекции:
- Pages;
- Posts;
- Media;
- Users;
- MarketingCampaigns.
Globals:
- Navigation;
- Footer;
- SiteSettings.
Этого набора достаточно для живого сайта магазина, где редактору нужно не только «загрузить картинку», но и собрать посадочную страницу, выпустить новость, поправить меню, обновить подвал, поменять настройки сайта или подготовить маркетинговую кампанию. Каталог и заказы при этом остаются в Medusa.
Drafts, preview и revalidation
В CMS-слое предусмотрены drafts, preview и revalidation. Для редактора и маркетолога это превращает CMS из «таблицы с полями» в нормальное рабочее место: можно спокойно подготовить страницу, проверить её до публикации и обновить storefront без ручного пересобирания всего проекта.
Но у такого удобства есть техническая цена: preview/revalidation должны быть защищены и правильно связаны с окружением. Staging и production не должны случайно использовать одни и те же secrets или endpoints. Сейчас production ещё не provisioned, поэтому эту границу нельзя считать закрытой.
Storefront и PAYLOAD_ENABLED
Storefront читает Payload только при PAYLOAD_ENABLED. Это правильный feature boundary: витрина получает контентный слой, когда он доступен, но магазин должен уметь жить без CMS-данных — особенно на раннем bootstrap или в окружении, где content layer временно выключен.
Content routes при этом должны иметь fallback/not-found поведение. Для пользователя отсутствие страницы должно выглядеть как нормальное состояние интерфейса, а не как stack trace из-за того, что маркетинговая страница ещё не опубликована или Payload временно недоступен.
MarketingCampaigns и коммуникации
MarketingCampaigns в Payload связаны с более широким marketing backend-контуром: preferences, campaigns, delivery journal, unsubscribe и double opt-in. В такой схеме CMS отвечает за понятную редакторскую часть кампаний, а backend — за согласия, доставку и следы коммуникаций. Это нужно, чтобы маркетинг не превращался в «отправить всем письмо из админки».
Нормальная маркетинговая система должна отвечать на вопросы, которые обычно становятся заметны только после первых реальных рассылок:
- кто дал согласие;
- на какой канал и тип коммуникации;
- какая кампания была отправлена;
- был ли delivery event;
- как пользователь может отписаться;
- как обрабатывается double opt-in.
В MedusaStore эта дисциплина заложена, но production-доведение всё равно требует проверки SMTP/mailserver, deliverability, retry, шаблонов и прав доступа. Поэтому Payload здесь не «кнопка рассылки», а часть более аккуратного процесса: подготовить кампанию, связать её с правилами коммуникации и не потерять контроль над тем, кому и почему она отправляется.
Граница с commerce truth
Payload не должен хранить:
- платежные секреты;
- provider credentials;
- финальную правду о заказах;
- checkout state;
- fulfillment decisions;
- товарные цены как источник истины.
Эти данные относятся к Medusa backend и интеграционному слою. CMS может делать витрину богаче: показывать промо-блоки, страницы, кампании и редакционные материалы вокруг магазина. Но она не должна становиться вторым commerce backend, иначе проект получит две конкурирующие версии правды.
Такой подход хорошо сочетается с общей архитектурой MedusaStore и напоминает принцип разделения источников в Quartz static catalog: контентный слой может помогать интерфейсу, но не должен ломать основной источник данных. Именно поэтому Payload в MedusaStore выглядит не как украшение сбоку, а как отдельный редакционный и маркетинговый слой, который усиливает storefront, не подменяя commerce-логику.