Strapi часто воспринимают как простую CMS для управления контентом. Это заблуждение мешает увидеть реальные возможности технологии. На практике Strapi оказывается швейцарским ножом веб-разработки — работает как no-code генератор, бэкенд фреймворк и при необходимости масштабируется до полноценного фулстек решения. Опыт создания маркетплейса автотоваров с десятками типов контента, сложной бизнес-логикой и интеграциями с внешними сервисами показал, что правильное использование Strapi позволяет запустить MVP за недели и развить его до энтерпрайз-системы без переписывания с нуля.
Статья написана на основе выступления разработчика компании Work Solutions на WS митапе.
Strapi как платформа: что из коробки и где писать код
Strapi — это кастомизируемый CMS-ориентированный бэкенд фреймворк. Его особенность в том, что из коробки предоставляется no-code редактор, платформа для генерации БД и CRUD API с возможностью управлять доступами и ролями. В административную панель входит headless CMS. Сам Strapi представляет себя на рынке как самая кастомизируемая open-source headless CMS.
Остановимся на том, что такое CMS. Это система управления контентом. На любом сайте есть динамический контент, который меняется со временем. Проблема такого контента в том, что потребность в его изменении часто возникает через много времени после прекращения сотрудничества заказчика с командой разработки. Функционал редактирования контента стоит особняком по отношению к функционалу просмотра, поэтому изменение БД и создание удобного графического интерфейса требует привлечения новых разработчиков и больших финансовых и временных затрат.
Преимущество таких систем как Strapi в автоматической генерации интерфейса для функционала управления и изменения контента. Интерфейс сам синхронизируется с базой данных.
Strapi позиционирует себя как headless CMS. Это означает, что CMS ответственна только за отображение и логику административной панели — той панели, которая скрыта от глаз конечного пользователя. В отличие от традиционных CMS, headless не генерирует публичный фронтенд, то есть витрину сайта или приложения.
Headless CMS становится все более популярным по двум причинам. Во-первых, количество платформ для отображения интерфейса очень велико — от телефонов до телевизоров и часов. Во-вторых, каждый заказчик стремится идентифицировать свой бренд по отношению к конкурентам. Headless CMS дает бизнесу возможность делать фронтенд независимым от CMS системы.
Когда возможностей «из коробки» не хватает, Strapi расширяется кодом: добавляете кастомные контроллеры и сервисы, подключаете middleware и политики, а также собственные плагины для админ-панели и сервера.
Strapi не единственный игрок в этой нише. Есть много конкурентов, но технология лидирует по узнаваемости и активности сообщества — это видно по динамике репозитория Strapi на GitHub и широте экосистемы плагинов в официальном маркетплейсе. В связке «быстрый старт + глубина кастомизации» это один из наиболее практичных выборов для продуктовых команд.
Быстрый старт в Strapi: установка, запуск и Content-Type Builder
Strapi предоставляет удобный CLI-интерфейс, с помощью которого можно инициализировать приложение с возможностью подключения TypeScript и интеграцией с одной из реляционных БД, таких как MySQL, MariaDB, PostgreSQL, SQLite.
После локального запуска приложения в режиме разработки административная панель будет доступна для дальнейшей работы. В начале никаких сущностей для редактирования не будет — база данных пока пустая. Администратор должен создать первые сущности через интерфейс Content-Type Builder.
Content-Type — общий термин в Strapi для обозначения сущностей в CMS и ресурсов в API. Есть два вида Content-Type: коллекционные и единичные.
Коллекционные типы (Collection Type) — множественные, например, статья в блоге или товар в магазине.
Единичные типы (Single Type) — сущность, которая не требует создания нескольких экземпляров, например данные одной страницы лендинга или связка токенов для аутентификации на внешних сервисах.
При сомнениях к какой категории отнести сущность, лучше выбирать коллекцию — это приближает разработку к проектированию БД. К тому же Single Type фактически является абстракцией над коллекцией с одной сущностью.
Поля и их типы
Любая сущность состоит из описывающих ее свойств — полей. Статья блога может иметь такие поля как название, изображение, автор, дата публикации. Поля имеют различные типы.
Пример коллекционного типа Article: базовые поля и связи в Content-Type Builder Strapi
Простые поля
Простые поля не требуют особого внимания: текстовые, числовые, булевые, календарный тип, перечисления для выбора одной из предзаданных опций.
Простые поля в Strapi: Text, Number, Boolean, Date, Email, Enumeration, JSON, Password
Media
Рассмотрим более интересные поля. Media Type позволяет загружать файлы. По дефолту файлы хранятся на сервере, но можно настроить интеграцию с облачными провайдерами — Amazon S3, Google Cloud Storage и Cloudinary.
Поле 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 zone: выбор компонентов при редактировании записи (конструктор блоков)
Работа с 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-строке
Strapi REST параметры в объекте: sort, filters, populate, fields, pagination
Используя 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.
Кастомный контроллер: получение id из ctx, вызов сервисного метода и возврат результата
В Strapi есть поддержка сервисов. В сервисах часто идет логика работы с БД. Для этого используется Document Service, построенный на библиотеке Knex. Интерфейс похож на эту библиотеку, но незначительно отличается. Синтаксис такой же, как при составлении query параметров в REST API. Особенность — поддержка транзакций.
Сервисный метод: выбор документа через documents().findOne с populate
После генерации метода контроллера его нужно ассоциировать с endpoint. Это делается через модуль конфигурации routes — указывается метод, абсолютный URL и название метода в контроллере. Здесь настраиваются middleware и политики.
Маршруты и политики: объявление пути /article/:id/something-specific, привязка хендлера, добавление policies и middlewares
Жизненный цикл запроса в Strapi
Запрос в Strapi проходит через четыре главных слоя: политики, middleware, контроллеры и сервисы. Весь код можно держать в контроллерах — это центральный слой. Но на больших проектах методы контроллера становятся большими, неподдерживаемыми с дублированным кодом.
Пайплайн запроса в Strapi: глобальные и маршрутные middleware → policy → контроллер/сервисы → ответ
Strapi имеет архитектурные возможности для делегирования логики контроллеров в атомарные сервисы. Политики — это «фейс-контроль» роута: они проверяют условия и решают, пускать ли запрос дальше в обработчик. Повторяющуюся инфраструктурную логику — логирование, маркировку запросов для аналитики и т.п. — выносится в middleware.
Жизненные циклы есть не только у запросов, но и у самого Strapi. Используя register и bootstrap методы, можно конфигурировать сервер перед инициализацией. Это идеальное место для конфигурации WebSocket.
Жизненный цикл приложения: этапы register() и bootstrap() перед обработкой запросов
Также есть жизненные циклы сущностей БД — на редактирование, создание, чтение. Важный момент — проблема миграций. В Strapi миграции происходят автоматически. С одной стороны это удобно, но при откате на прошлую версию приложения, где еще не было половины контент-типов, Strapi автоматически запустит миграцию, удалит таблицы и вместе с ними данные. Таблицы вернутся при возврате в актуальную версию приложения, но данные уже не вернутся. Правильный вариант — делать регулярно бэкапы либо отключить автомиграции через конфигурацию.
Несмотря на автоматические миграции, Strapi позволяет писать их самостоятельно. Это нужно, например, для переноса данных между таблицами и проставления индексов — а также для других задач оптимизации БД, которые нельзя выполнить через интерфейс или JSON.
Пример миграции: добавление индекса по полю slug для таблицы articles
Возможность полной кастомизации бэкенда опровергает миф об ограниченности Strapi из-за связки с CMS. На практике можно работать со Strapi как с обычным бэкенд-фреймворком, а административную панель добавить позже, когда структура данных устоится. Такой подход экономит время на старте проекта.
Плагины
Когда коробочных возможностей Strapi недостаточно, на помощь приходят плагины.
Плагины — это код, который расширяет админ-панель или серверную часть Strapi.
В Strapi есть встроенные плагины при инициализации приложения. Например, планировщик задач cron для интервальных действий, email для почтовых уведомлений или плагин для управления доступами к внешнему API.
Помимо них есть официальный marketplace с плагинами — кастомное поле выбора цвета, генератор Swagger документации, поддержка GraphQL, интеграция с большими языковыми моделями от OpenAI, интернационализация. Всё это можно подключить в проект через marketplace.
Официальные плагины Strapi в Marketplace: GraphQL, Documentation (OpenAPI), SEO, i18n, Color picker, Open AI, Sentry
Существуют community плагины от обычных пользователей. Это возможно благодаря интерфейсу для создания и публикации плагинов. В эти плагины часто нужно заглядывать. В Strapi нет возможности через графический интерфейс сделать поле типа relation обязательным, но в Strapi 5 есть community плагин required relation field.
Можно создавать собственные плагины. Часто заказчику нужны UI виджеты, выходящие за рамки Strapi. Это делается при помощи инициализации через npx. Создается кодовая база, разделенная на server и admin.
Server выглядит так же, как обычная работа с сервером. Фронт админ-панели — React, интегрированный с React Router и Redux. Важная особенность Strapi — собственная дизайн-система, построенная на Storybook и работающая на базе Radix UI. Можно импортировать ее для быстрого создания качественного UI, не отличающегося от нативных компонентов Strapi.
Есть две основные стратегии интеграции плагина в CMS. Добавляется кастомная ссылка в сайдбар, ведущая на собственный виджет. Также можно регистрировать кастомное поле для дальнейшего добавления в сущность.
Добавление пункта меню для плагина: app.addMenuLink указывает маршрут и компонент виджета
Регистрация кастомного поля в админке: app.customFields.register (тип, иконка, компонент ввода)
Стираются границы между CMS и фулстек фреймворком — бэкенд и фронтенд работают в общей экосистеме Strapi с поддержкой интернационализации. Плюс плагинов в возможности создать несколько плагинов и переиспользовать их в разных проектах.
Реальный кейс: маркетплейс на Strapi
Рассмотрим реальный кейс — маркетплейс на Strapi для крупного сервиса по покупке и сервисному обслуживанию автомобилей.
Работа началась с генерации контент-типов. Их получилось много. Использовались коллекции. Центральной коллекцией стал товар. Была коллекция под категорию. Использовался двусторонний relation — это сделало удобное API и дало возможность контент-менеджерам осуществлять удобную навигацию между исходными и целевыми сущностями.
В ход пошли динамические зоны. Была сложная логика, при которой каталоги товаров различались в зависимости от категории. В каждом каталоге была разная конфигурация фильтров. Для масел — фильтр по вязкости, для ковриков — по материалу. Контент-менеджеры получили возможность самостоятельно выбирать набор и порядок фильтров для каждого каталога. Для этого использовались динамические зоны.
Пример каталожных фильтров: каждый раздел получает свой набор полей (производитель, сезонность, крепление, ценовой диапазон и т.д.)
Не обошлось без Single Types. Главная страница в приложении была одна, но ее структура должна была быть редактируемой. Поэтому для неё выбрали Single Type, а не коллекцию.
Товаров было много, поэтому на проект привлекли несколько контент-менеджеров еще на этапе активной разработки. Критически важно было точечно настроить доступы, чтобы контент-менеджеры могли редактировать только определенные поля без нарушения значений технических и важных полей.
Интересный кейс с кастомизацией аутентификации. По дефолту в Strapi авторизация по email и паролю. Требовалось сделать авторизацию по номеру телефона с кодом подтверждения. Интегрировались с сервисом Megafon и кастомизировали плагин users-permissions. Переопределили контроллеры и методы. Endpoints остались те же, но логика стала кастомная. Strapi позволил это сконфигурировать.
На Strapi 4 еще не было удобных плагинов для обязательности поля типа relation. Обошли проблему через хуки жизненного цикла и создали функцию для проверки обязательности relation поля с выводом кастомного сообщения об ошибке.
Проверка «обязательного relation» на lifecycle: хук помечает незаполненную связь и показывает ошибку в админке
Была сложная логика ценообразования. Цена складывалась из себестоимости товара, скидок, процента наценки поставщика. Все должно храниться в БД и производить пересчет. Хуки жизненного цикла активно использовались для реализации. При обновлении любого из полей начиналось транзакционное обновление цен.
В проекте реализовали расширения UI панели. Центральный плагин — импорт товаров из Excel. Поставщик присылал файл, форма позволяла загрузить файл поставщика. Система проверяла формат файла, делала парсинг и импортировала товары в БД с выводом аналитики — сколько обновлено, сколько удалено.
Кастомный плагин импорта: загрузка XLSX, валидация и отчёт по добавленным/обновлённым позициям
Отдельный пласт работ по интеграции интернет-магазина со службой доставки СДЭК. Сделан proxy API для решения проблем с CORS на стороне фронтенда. Создан кастомный виджет для управления заказами и их регистрации. Реализована возможность автоматически генерировать накладные, отправлять их по почте поставщикам, обновлять статусы через СДЭК webhook.
Виджет регистрации заказов в СДЭК: поиск по номеру, формирование отправлений и регистрация через API
Сделали вложенный сайдбар через дизайн-систему Strapi. По виду не отличается от нативных компонентов Strapi.
Никакой магазин не может существовать без эквайринга и оплаты. Реализовали сплитование платежей и кастомный виджет с формой для регистрации маркетплейса в банке.
Последнее — функционал привязки товара к авто. Каждый товар привязан к конфигурации автомобиля с разной степенью детализации в зависимости от категории. Сделали отдельный плагин, сложную таблицу для работы менеджеров. Осуществили интеграцию со сторонним API для получения подсказок по артикулу о соответствии конфигурациям товара. Это значительно ускорило работу контент-менеджеров.
Форма подбора конфигурации авто: марка, модель, поколение, модификация — для связи товара с конкретными авто
На этом проекте Strapi проявил себя во всех ипостасях — как CMS, no-code генератор, backend фреймворк и фулстек фреймворк. Получилось сделать оптимизированную логику в разумные сроки.
Подробный разбор кейса доступен в отдельной статье.
Подводные камни
Идеальных инструментов не существует, везде есть подводные камни. Обратим внимание на несколько из них.
Для надежного бэкенда важна строгая типизация. В 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 за недели и масштабировать его до полноценной системы без переписывания с нуля.
