После запуска MVP на Strapi возникает вопрос: как дальше масштабировать систему? Наш опыт создания маркетплейса автотоваров с десятками типов контента показал, что Strapi в продуктиве — это не просто CMS, а полноценный бэкенд-фреймворк с глубокой кастомизацией.
Статья написана на основе выступления разработчика компании Work Solutions на WS митапе.
Strapi как платформа: что из коробки и где писать код
В контексте прода: Strapi — это кастомизируемый CMS-ориентированный бэкенд-фреймворк. Обычно под фреймворками понимают более низкоуровневые технологии вроде Nest в экосистеме Node.js, но на практических примерах покажем, что Strapi сопоставим по степени контроля и расширяемости. Теорию и сравнение с классическими CMS мы уже разобрали в большом обзоре «Что такое Strapi CMS: полное руководство». Здесь — только практика: где заканчиваются клики в админке и начинается код.
Главная ценность Strapi в продакшн-разработке — возможность начать с визуального конструктора и постепенно наращивать кастомизацию. Модель данных создается через UI за минуты, REST API генерируется автоматически, права доступа настраиваются в пару кликов. Но когда бизнес-логика усложняется, то появляются транзакции, сложные валидации, интеграции с внешними сервисами. Strapi здесь не становится ограничением. Под капотом это Node.js и Koa, а значит полный контроль над кодом.
Три уровня работы со Strapi
Strapi предлагает три уровня кастомизации: no-code (визуальный конструктор), low-code (плагины и простые контроллеры) и full-code (полная кастомизация бэкенда). Базовые возможности каждого уровня подробно разобраны в статье «Fullstack-разработка: как начать создавать приложение за неделю со Strapi».
В этом материале сосредоточимся на full-code уровне, на том, что критично именно для продакшена: транзакции, lifecycle hooks, оптимизация запросов, кастомные плагины с UI и production-grade архитектура.
Экосистема и сообщество
Strapi не единственный игрок в этой нише. Есть много конкурентов, но технология лидирует по узнаваемости и активности сообщества — это видно по динамике репозитория Strapi на GitHub и широте экосистемы плагинов в официальном маркетплейсе. В связке «быстрый старт + глубина кастомизации» это один из наиболее практичных выборов для продуктовых команд.
Архитектура контент-типов: какие поля критичны для production
Strapi предоставляет CLI для инициализации проекта с TypeScript и PostgreSQL/MySQL. Content-Type Builder позволяет создавать модели через UI — базовый процесс описан в статье про быстрый старт. Здесь разберем продвинутые типы полей, которые становятся критичными в продакшн-проектах: работа с медиа, структурированный Rich Text, автогенерация UID и гибкие Dynamic Zones.
Простые поля
Простые поля не требуют особого внимания: текстовые, числовые, булевые, календарный тип, перечисления для выбора одной из предзаданных опций.
Простые поля в Strapi: Text, Number, Boolean, Date, Email, Enumeration, JSON, Password
Media
Рассмотрим более интересные поля. Media Type позволяет загружать файлы. По умолчанию файлы хранятся на сервере, но можно настроить интеграцию с облачными провайдерами и S3-хранилищами — Яндекс Облако, VK Cloud, Selectel и др.
Поле Media в Strapi: загрузка файлов и работа с изображениями, видео и др.
Rich Text
Rich Text нужен для создания форматированного текста. Strapi предлагает на выбор два встроенных редактора: классический Markdown и более продвинутый WYSIWYG, который называется Blocks и является рекомендуемым вариантом. Особенность в том, что в API такой текст возвращается не простой строкой с HTML, а в виде структурированного JSON-объекта, где каждый элемент форматирования — это отдельный блок. Что может показаться избыточным, но именно это даёт огромное преимущество для фронтенда. Для React-приложений официальная команда платформы поддерживает библиотеку @strapi/blocks-react-renderer, которая значительно упрощает кастомизацию отображения этого JSON под дизайн вашего приложения. Для других фреймворков, например для Vue, существуют community-решения, такие как vue-strapi-blocks-renderer.
Rich text (Blocks) — редактор Strapi на базе JSON-блоков
Структура Rich text (Blocks): пример JSON-представления параграфа и текста
UID
Интересный тип поля — уникальный идентификатор UID. Его особенность в генерации значений на основе другого поля. Часто используется для слагов — человекочитаемых URL. Поле также используется для генерации уникальных идентификаторов в целом. Конвертирует кириллицу в латиницу. Корпоративный блог Work Solutions работает именно с использованием этого поля.
Поле UID — генерация человекочитаемых URL на базе другого поля
Relation
Один из самых важных типов — поле Relation или связь. Позволяет выстраивать связи к единичной или множественным сущностям. Связи бывают односторонние и двусторонние. При создании связи Strapi создает в админ-панели виджеты, кликнув на которые можно сразу перейти в целевую сущность. Это упрощает навигацию для контент-менеджеров.
Component
Тип Component позволяет группировать поля для переиспользования в разных контент-типах. Конфигурация соответствует конфигурации контент-типа, но компонент не может существовать вне контент-типа. Может быть как единичным, так и множественным. Порядок можно менять с помощью drag-and-drop.
Component в Strapi: переиспользуемые группы полей
Dynamic Zones
Динамические зоны позволяют задать набор переиспользуемых компонентов для выбора в каждой сущности коллекции отдельно. Идеальный кейс — конструктор страницы.
Dynamic zone: выбор компонентов при редактировании записи (конструктор блоков)
Про сборку страниц на Dynamic Zones и корпоративный «конструктор» мы рассказали отдельно —«Свой корпоративный конструктор сайтов».
Работа с CMS
После создания сущностей администратор может зайти в CMS и приступить к управлению. Сущности по умолчанию у Strapi бывают двух статусов: черновик и публикация. Черновики не попадают в конечный ответ API, скрыты от конечного пользователя. Это позволяет контент-менеджерам итеративно наполнять контент и не раскрывать незавершенные состояния конечным пользователям. Публикацию можно откатить в статус черновика — это скрывает ее от конечного пользователя без удаления данных и сущности.
Редактирование записи в Strapi: поля автора, аватар (Media) и связанные статьи
Strapi имеет удобный интерфейс для кастомизации вида. Поля и их расположение можно менять. При просмотре коллекции есть таблица с фильтрацией, сортировкой, поиском и настройкой столбцов. Настройки отображения применяются ко всем пользователям административной панели.
Список записей в коллекции: поиск, фильтры, настраиваемые колонки и сортировка
В больших проектах часто имеет смысл разделить группы контент-менеджеров. Например, создать роль контент-менеджера с возможностью редактировать целевые товары без доступа к техническим и критически важным данным. Это делается точечно через Strapi.
Гранулярные права в Strapi: Create/Read/Update/Delete/Publish по типам контента
API из коробки: CRUD, аутентификация, роли и query-параметры
После создания контент-типа генерируется не только CMS, но и первичный CRUD API. Вместе с ним генерируются эндпоинты для авторизации и регистрации пользователей. Strapi по умолчанию создает коллекцию внешних пользователей API.
Список пользователей API в админке: username, email, статус подтверждения
Регистрация по умолчанию делается по email и паролю, Strapi добавляет поля email, пароль и username. Эта сущность относится также к контент-типу, ее можно расширять. Например, можно добавить поля для авторизации по номеру телефона или данные профиля.
Редактирование пользователя: стандартные поля и кастомные атрибуты (например, phone)
Как и в случае с CMS, роли и доступы к внешнему API также конфигурируются. По умолчанию у внешних пользователей две роли — неавторизованный и авторизованный. Можно создать больше ролей и для каждого эндпоинта через интерфейс выставить доступы.
Strapi Permissions: настройка прав Public/Authenticated и API-эндпоинтов для коллекции Article
Через API можно делать фильтрацию, сортировку, пагинацию через систему query параметров. Также можно делать джойны внутренних сущностей через populate.
Пример запроса к REST API Strapi: сортировка, фильтры, populate, выбор полей и пагинация в query-строке
Параметры GET-запроса к REST API Strapi
Используя Strapi, можно создать первичный backend без написания кода. Опционально генерируется OpenAPI спецификация. При использовании Strapi на TypeScript можно сгенерировать типы и переиспользовать их во frontend приложении. Интеграция фронтенда с бэкендом будет следовать строгой типизации.
Нужна ли кастомизация API
Стоит рассмотреть, имеет ли смысл использовать API без кастомизации. У этого подхода есть плюсы. Фронтенд становится максимально зависимым от бэкенда. Налаживается коммуникация между отделами — сначала есть бэкенд, потом функциональность реализуется на фронтенде. Уменьшается количество ошибок интеграции — при изменении на стороне БД фронтенд проекты просто не скомпилируются при использовании TypeScript.
Есть независимость от требований клиентов. В приложении для стоматологии может быть приложение для пациента и отдельное приложение для доктора. Они используют ту же бизнес-модель и предметную область. Ее логично хранить в одной админке, но требования к передаче данных на эти клиенты будут разные. Здесь можно использовать паттерн backend for frontend (BFF).
У подхода есть обратная сторона. Любое изменение на стороне бэкенда, даже переименование поля, приводит к необходимости менять компоненты на всем фронтенде. Второй минус — жесткая привязка фронтенда к базе данных. Фронтенд работает не со слоем бизнес-логики, а напрямую с проекцией БД. Это мешает параллельной работе команд. Часто фичей занимаются фронтенд и бэкенд отделы параллельно. Это можно делать через контрактно-ориентированную разработку, но это невозможно без кастомизации API.
Хорошие новости — кастомизировать API в Strapi не сложно. Strapi по большому счету обычный бэкенд на Koa — фреймворке от команды, которая разрабатывала Express.
Кастомизация бэкенда в Strapi
После генерации контент-типов кодовая база автоматически генерируется в папке API. Код разбит по сущностям. Через JSON-файл можно конфигурировать модель и метаинформацию контент-типа. Все действия из графического редактора можно делать через JSON — определять поля, правила валидации.
schema.json: атрибуты, UID-слаг, Media и Relation — тот же контракт, что задается в админке
Для кастомизации API часто нужно делать собственные хендлеры запросов. Это делается через расширение контроллера. Сигнатура методов полностью повторяет сигнатуру хендлеров запросов в Koa. При отсутствии информации в документации Strapi о контексте — аргументе хендлеров, можно посмотреть документацию Koa.
Кастомный контроллер: получение query-параметра из запроса, вызов сервисного метода и возврат результата
В Strapi есть поддержка сервисов. В сервисах часто идет логика работы с БД. Для этого используется Document Service, построенный на библиотеке Knex. Интерфейс похож на эту библиотеку, но незначительно отличается. Синтаксис такой же, как при составлении query параметров в REST API. Особенность — поддержка транзакций.
Сервисный метод: выбор документа через documents().findOne с populate
После генерации метода контроллера его нужно ассоциировать с endpoint. Это делается через модуль конфигурации routes — указывается метод, абсолютный URL и название метода в контроллере. Здесь настраиваются middleware и политики.
Маршруты и политики: объявление пути /article/:id/something-specific, привязка хендлера, добавление policies и middlewares
Жизненный цикл запроса: куда выносить логику
На продакшене понимание жизненного цикла запроса критично для отладки, оптимизации и правильной организации кода. Когда эндпоинтов десятки, а бизнес-логика включает проверки прав, валидацию, работу с внешними сервисами, в таком случае важно знать, на каком слое что размещать. Детальное описание архитектуры обработки запросов в Strapi смотрите в статье про быстрый старт. Здесь разберем типичные ошибки и паттерны, которые проявляются именно на больших проектах.
Пайплайн запроса в Strapi: глобальные и маршрутные middleware → policy → контроллер/сервисы → ответ
Strapi имеет архитектурные возможности для делегирования логики контроллеров в атомарные сервисы. Политики — это «фейс-контроль»: они проверяют условия и решают, пускать ли запрос дальше в обработчик. Повторяющуюся инфраструктурную логику — логирование, маркировку запросов для аналитики и т.п. — выносят в middleware.
Жизненные циклы есть не только у запросов, но и у самого Strapi. Используя register и bootstrap методы, можно конфигурировать сервер перед инициализацией. Это идеальное место для конфигурации WebSocket.
Жизненный цикл приложения: этапы register() и bootstrap() перед инициализацией сервера
Также есть жизненные циклы сущностей БД — на редактирование, создание, чтение. Важный момент — проблема миграций. В Strapi миграции происходят автоматически. С одной стороны это удобно, но при откате на прошлую версию приложения, где еще не было половины контент-типов, Strapi автоматически запустит миграцию, удалит таблицы и вместе с ними данные. Таблицы вернутся при возврате в актуальную версию приложения, но данные уже не вернутся. Правильный вариант — делать регулярно бэкапы либо отключить автомиграции через конфигурацию.
Несмотря на автоматические миграции, Strapi позволяет писать их самостоятельно. Это нужно, например, для переноса данных между таблицами и проставления индексов — а также для других задач оптимизации БД, которые нельзя выполнить через интерфейс или JSON-схемы.
Пример миграции: добавление индекса по полю slug для таблицы articles
Возможность полной кастомизации бэкенда опровергает миф об ограниченности Strapi из-за связки с CMS. На практике можно работать со Strapi как с обычным бэкенд-фреймворком, а административную панель добавить позже, когда структура данных устоится. Такой подход экономит время на старте проекта.
Плагины в продакшн: когда писать свои
На проде встречаются задачи, в которых коробочных возможностей Strapi недостаточно. Базовая архитектура плагинов описана в этой статье. Здесь разберём продакшн-сценарии и подводные камни.
Плагины — это код, который расширяет админ-панель или серверную часть Strapi.
Community-плагины закрывают узкие места базового функционала. В Strapi нет возможности через графический интерфейс сделать поле типа relation обязательным, но в Strapi 5 есть community плагин required relation field.
Когда нужны собственные плагины
Специфичная бизнес-логика требует кастомных решений. Массовый импорт данных с валидацией на сотни тысяч записей нуждается в фоновых очередях — стандартный upload через админку упрется в лимиты памяти и таймауты. Интеграция с внешними API (платежные системы, логистика, аналитика) требует собственной обработки ошибок, retry-механизмов и кэширования. Кастомные дашборды с бизнес-метриками невозможны без отдельного UI-слоя и API для агрегации данных.
Подводные камни production-плагинов
Изоляция зависимостей. Плагин работает в контексте всего приложения Strapi — конфликты версий npm-пакетов могут сломать как плагин, так и ядро. Используйте peerDependencies и тестируйте совместимость.
Миграции данных. При обновлении структуры плагина нужны собственные миграции — автоматические миграции Strapi их не покрывают. Храните версионность схемы и пишите rollback-скрипты.
Производительность UI. React-компоненты плагина рендерятся в общем дереве админки. Тяжёлые вычисления или частые ререндеры тормозят всю панель. Используйте мемоизацию и выносите сложную логику в Web Workers.
Переиспользование между проектами
Переиспользование плагинов между проектами дает эффект масштаба. Важно изначально проектировать их как независимые модули с конфигурацией через environment variables. Плагин интеграции с платежной системой или сервисом доставки, написанный для одного проекта, затем применяется в других с минимальными правками.
Реальный кейс: маркетплейс на Strapi
На одном из проектов Strapi использовался как CMS, no-code-стартер и дальше как бэкенд-фреймворк. Полный разбор кейса доступен в статье «Интернет-магазин на Strapi и Next.js». Здесь опишем технические решения и подводные камни эксплуатации.
Работа началась с генерации контент-типов. Их получилось много. Центральной коллекцией стал товар. Была коллекция под категорию. Использовался двусторонний relation — это сделало удобное API и дало возможность контент-менеджерам осуществлять удобную навигацию между исходными и целевыми сущностями.
В ход пошли динамические зоны. Была сложная логика, при которой каталоги товаров различались в зависимости от категории. В каждом каталоге была разная конфигурация фильтров. Для масел — фильтр по вязкости, для ковриков — по материалу. Контент-менеджеры получили возможность самостоятельно выбирать набор и порядок фильтров для каждого каталога. Для этого использовались динамические зоны.
Пример каталожных фильтров: каждый раздел получает свой набор полей (производитель, сезонность, крепление, ценовой диапазон и т.д.)
Не обошлось без Single Types. Главная страница в приложении была одна, но ее структура должна была быть редактируемой. Поэтому для нее выбрали Single Type.
Товаров было много, поэтому на проект привлекли несколько контент-менеджеров еще на этапе активной разработки. Критически важно было точечно настроить доступы, чтобы контент-менеджеры могли редактировать только определенные поля без нарушения значений технических и важных полей.
Кастомизация под продакшн
Интересный кейс с кастомизацией аутентификации. По умолчанию в Strapi авторизация по email и паролю. Требовалось сделать авторизацию по номеру телефона с кодом подтверждения. Интегрировались с сервисом Megafon и кастомизировали плагин users-permissions. Переопределили контроллеры и методы. Endpoints остались те же, но логика стала кастомная.
На Strapi 4 ещё не было удобных плагинов для обязательности поля типа relation. Обошли проблему через хуки жизненного цикла и создали функцию для проверки обязательности relation поля с выводом кастомного сообщения об ошибке.
Пример кастомной валидации обязательных связей: система блокирует сохранение и указывает на незаполненное поле
Была сложная логика ценообразования. Цена складывалась из себестоимости товара, скидок, процента наценки поставщика. Все должно храниться в БД и производить пересчет. Хуки жизненного цикла активно использовались для реализации. При обновлении любого из полей начиналось транзакционное обновление цен.
Плагины для бизнес-логики
В проекте реализовали расширения UI панели. Центральный плагин — импорт товаров из Excel. Поставщик присылал файл на тысячи строк, форма позволяла загрузить его. Система проверяла формат, делала парсинг и импортировала товары в БД через фоновые очереди с выводом аналитики — сколько обновлено, сколько добавлено.
Кастомный плагин импорта: загрузка XLSX, валидация и отчёт по добавленным/обновлённым позициям
Отдельный пласт работ по интеграции интернет-магазина со службой доставки СДЭК. Сделан proxy API для решения проблем с CORS на стороне фронтенда. Создан кастомный виджет для управления заказами и их регистрации. Реализована возможность автоматически генерировать накладные, отправлять их по почте поставщикам, обновлять статусы через СДЭК webhook.
Виджет регистрации заказов в СДЭК: поиск по номеру, формирование отправлений и регистрация через API
Сделали вложенный сайдбар через дизайн-систему Strapi. По виду не отличается от нативных компонентов Strapi.
Никакой магазин не может существовать без эквайринга и оплаты. Реализовали сплитование платежей и кастомный виджет с формой для регистрации маркетплейса в банке.
Последнее — функционал привязки товара к авто. Каждый товар привязан к конфигурации автомобиля с разной степенью детализации в зависимости от категории. Сделали отдельный плагин, сложную таблицу для работы менеджеров. Осуществили интеграцию со сторонними API для получения подсказок по артикулу о соответствии конфигурациям товара. Это значительно ускорило работу контент-менеджеров.
Форма подбора конфигурации авто: марка, модель, поколение, модификация — для связи товара с конкретными авто
Проект продемонстрировал, как Strapi масштабируется от простой CMS до полноценного бэкенда с глубокой кастомизацией. Получилось реализовать оптимизированную логику в разумные сроки.
Подводные камни
Идеальных инструментов не существует, везде есть подводные камни. Обратим внимание на несколько из них.
Для надежного бэкенда важна строгая типизация. В Strapi есть интеграция с TypeScript с четвертой версии, но пока не идеальна. В конфигурации TypeScript типизация не строгая, strict выставлен в false. Рекомендуется при инициализации приложения сразу заменить на true. Приложение вначале не скомпилируется, но там всего три строчки для типизации несложным образом. Весь последующий код будет со строгими типами и с ним будет надежнее работать.
В Strapi есть нюанс с глобальным синглтоном: при обращении к сервисам через него типы в TypeScript часто теряются. Решение — не обязательно подключать все сервисы в singleton. Можно создать класс, протипизировать и импортировать напрямую в контроллерах или других сервисах.
Сервисы без глобального singleton: использование конкретного articleService вместо strapi.service(...)
Обращаем внимание на populate со звездочкой и populate deep. При запросе сущности в ответ попадают только примитивные поля, без полей вложенных сущностей. Они добавляются через populate — пишется название полей для добавления в запрос. Есть шорткаты — можно написать звездочку для добавления всех полей. Можно использовать community плагин populate deep для максимальной вложенной популяции.
Правильно: выбирать только нужные поля и точечно populate; Неправильно: populate "*" во всех запросах
На тестовых данных проблем с производительностью может не быть, но на продакшене практически гарантирована ошибка heap out of memory. Чтобы избежать, нужно выработать привычку указывать в каждом запросе только нужные поля для конкретного случая. Правило действует и для примитивных полей — их тоже можно селектировать как в базе данных. Приложение будет работать быстрее.
Еще пункт — миф об односторонней связи. При создании связи товара с категорией часто достаточно проставить внешний ключ в одну из таблиц. Дальше можно джойнить как угодно. Многие разработчики думают, что нужно использовать одностороннюю связь relations в Strapi.
Двусторонняя связь делает UI виджеты как в исходной, так и в целевой сущности. Односторонняя связь этого не делает. Многие идут на неудобство для контент-менеджеров в надежде оптимизировать БД, создать меньше таблиц. По факту этого не происходит в большинстве случаев. Рекомендуется руководствоваться требованиями контент-менеджеров.
Последнее — миф о количестве плагинов. При инициализации нового плагина он автоматически интегрируется в сайдбар. Может показаться, что для каждого раздела в сайдбаре нужен отдельный плагин. Это не так. Можно сделать один плагин и подключить несколько разделов через него. Иногда это оптимальней — общая кодовая база, общие зависимости, общая доменная логика.
Создание отдельного плагина не плохая практика. Но перед созданием нового раздела подумайте, нужен ли отдельный плагин. Хотите ли упаковать его как отдельный пакет.
Выводы и рекомендации
После работы с множеством проектов различной сложности можно с уверенностью сказать — Strapi это не просто CMS, а полноценная платформа для создания веб-приложений. Главная сила в балансе между скоростью старта и глубиной кастомизации.
Начиная проект, получаете готовую админку, API и систему управления доступами без написания кода. Это экономит недели разработки на начальном этапе. Когда требования усложняются, Strapi не становится ограничением — просто начинаете писать код там, где это необходимо. Контроллеры, сервисы, middleware, кастомные плагины — все инструменты профессиональной разработки в распоряжении.
Опыт создания маркетплейса показал, что Strapi справляется с задачами enterprise-уровня. Сложная бизнес-логика, интеграции с внешними системами, кастомные интерфейсы для специфических задач — все это реализуемо и поддерживаемо. При этом контент-менеджеры получают удобный инструмент для работы с первого дня разработки.
Главная рекомендация — не ограничивайте восприятие Strapi рамками простой CMS. Изучите возможности на низком уровне, поймите архитектуру, освойте создание плагинов. Это инвестиция, которая окупится уже на первом серьезном проекте.
Strapi не идеален — есть подводные камни с типизацией, производительностью при неправильном использовании populate, особенности миграций. Но зная эти моменты и следуя best practices, получаете инструмент, который позволяет запустить MVP за недели и масштабировать его до полноценной системы без переписывания с нуля.
Strapi не идеален — есть подводные камни с типизацией, производительностью при неправильном использовании populate, особенности миграций. Но зная эти моменты и следуя best practices, получаете инструмент, который позволяет запустить MVP за недели и масштабировать его до полноценной системы без переписывания с нуля.
