Создание сайта на Cockpit CMS: headless-бэкенд для Next.js и Nuxt

Разработка сайта на Cockpit CMS: где ломается контентный слой

Сайт живёт годами: сначала десяток страниц, потом каталог, блог, раздел с документами. Контент в такой схеме вшит прямо в шаблоны — заголовок, описание и таблица характеристик лежат в разметке, а правка одного пункта означает новую сборку и выкладку. Чем больше разделов, тем чаще ручные правки контента идут мимо репозитория: текст поправили в редакторе, следующая выкладка его затёрла.

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

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

Разбираем, как это закрывается при разработке сайта на Cockpit CMS: фиксированной схемой коллекций, единым контрактом выдачи для всех шаблонов и сбросом кеша по событию публикации. Дальше — что именно ломается в контентном слое и как мы это чиним.

Что даёт headless-схема: скорость правок и порядок в слоях

Разделение слоёв — это когда контент живёт в админке, а разметка и логика остаются в коде фронтенда. Редактор меняет текст, изображения и порядок блоков, не дожидаясь ближайшего релиза; разработчик не пересобирает проект из-за правки заголовка. В headless-схеме данные отдаёт отдельный бэкенд на Cockpit CMS, а страницы собирает фронтенд на актуальной ветке Next.js или Nuxt — у двух контуров свои циклы выпуска, и они больше не блокируют друг друга.

Что это меняет на практике:

• Скорость публикации контента — правка уходит на прод за минуты, а не ждёт окна выката. Раньше типовое обновление «поправить анонс и баннер» растягивалось на день-два; теперь это одно действие редактора.
• Отдача страниц под нагрузкой — страницы отдаются как подготовленные, а тяжёлые запросы к данным живут отдельно от ответа пользователю. На пике трафика время отклика не растёт пропорционально числу запросов: добавляется кеш, а не мощность серверов.
• Число обращений к разработчику на одну правку — типовые задачи (новый раздел, карточка, поле в шаблоне) закрываются готовыми типами контента. Разработчик нужен примерно на одну правку из десяти-пятнадцати — остальное редактор делает сам.
• Независимый откат — неудачную публикацию откатывают версией контента, неудачный релиз — предыдущей сборкой. Одно не тянет за собой другое.
• Предсказуемая миграция оформления — смена вёрстки, шаблонов или фронтенд-фреймворка не требует переложить контент: структура данных остаётся той же.

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

Режимы работы: классическая база, headless-бэкенд, гибрид

Режим работы с контентом выбирают не по вкусу, а по тому, кто рендерит страницу и как часто её содержимое меняется. Cockpit CMS хранит материалы в коллекциях и отдаёт их через программный интерфейс, поэтому один и тот же набор данных может обслуживать и классический сайт, и отдельный фронтенд на Next.js или Nuxt. Разница проявляется в способе генерации страниц, скорости отдачи и в том, какие правки редактор может внести самостоятельно.

На практике смена режима почти не затрагивает сам контент: коллекции, поля и связи остаются теми же, меняется только слой доставки. Поэтому стартуем с более простой схемы, а предварительную генерацию или отдельный headless-слой подключаем тогда, когда появляется второй потребитель данных либо требования к скорости отдачи.

Порядок работ: контентные модели, сборка, проверка, передача

Работы идут от разбора текущей структуры данных к сайту, готовому к правкам, поэтому контентные модели проектируются до вёрстки: если схему меняют по ходу, приходится переделывать разметку, связи между разделами и весь перенос данных. Ниже — порядок, по которому мы ведём проект.

1. Инвентаризация контента. Разбираем существующие разделы, записи, справочники и связи между ними, фиксируем, что переиспользуем, а что переносим в новую структуру.
2. Контентные модели. Описываем типы записей, поля, обязательность, справочники и языковые версии; закладываем черновики, чтобы правка не попадала на сайт сразу.
3. Схема разделов и навигации. Собираем дерево страниц, хлебные крошки, правила адресов и переадресаций со старых ссылок — иначе позиции теряются при смене структуры.
4. Перенос данных. Готовим выгрузку, убираем дубли, сопоставляем поля старых записей с новыми моделями и сверяем количество и связи до и после загрузки.
5. Сборка и вывод. Настраиваем выдачу контента из Cockpit CMS во фронтенд, кеширование и пересборку страниц при публикации; предпросмотр отделён от рабочей версии.
6. Проверка. Прогоняем формы, роли и права доступа, поиск, адреса и точки вывода, сверяем ключевые страницы с согласованной структурой.
7. Передача и регламент правок. Отдаём доступы, описание моделей и порядок работы: как добавить раздел, поле или точку вывода без правки кода.

Каждый этап закрывается короткой демонстрацией на тестовом окружении — заказчик видит результат до того, как он уйдёт в рабочую версию.

Что остаётся у вас: схемы коллекций, права, регламенты

Артефакты создаются по ходу работ, а не в конце «для галочки»: документация обновляется вместе с моделью контента, иначе через месяц она описывает то, чего уже нет. Ниже полный перечень того, что вы получаете на руки.

• Схемы коллекций — по каждому типу материала: состав полей, типы, обязательность, значения по умолчанию, правила проверки на стороне бэкенда и связи между коллекциями. Этого достаточно, чтобы добавить поле или новый тип записи без разбора исходного кода.
• Описание справочников и словарей — какие значения существуют, где используются, кто отвечает за пополнение и что произойдёт с уже опубликованными материалами при переименовании значения.
• Матрица прав доступа — роли сведены в таблицу «роль × коллекция × действие», отдельно выделены публикация, снятие с публикации и удаление. Видно, кто и что может, и куда обращаться за расширением прав.
• Инструкции для редакторов — пошаговые сценарии с экранами: как завести материал, прикрепить медиа, поставить в очередь публикации и что делать, если материал не прошёл проверку полей.
• Карта интеграций — список внешних систем, события, по которым идёт обмен, формат данных и порядок действий при недоступности внешней стороны.
• Регламент резервного копирования — что копируется, с какой периодичностью, как проверить пригодность копии и как восстановить отдельную коллекцию, не откатывая весь сайт.
• История изменений модели контента — журнал правок схем с указанием, какие данные нужно перенести после каждого изменения.

Передача идёт по чек-листу: проходим по каждому пункту вместе с вашей командой, проверяем, что доступы выданы, инструкции воспроизводимы, а обновление схемы на тестовом контуре не ломает опубликованные материалы.

Разбор проекта: каталог на headless-схеме, метрики до и после

Каталог на 12 000 позиций жил в монолите: правка карточки или цены шла через админку, и публикация одной страницы занимала до 40 минут — редактор ждал пересборки всего сайта. Прайс заливали ночным импортом, категории после него сверяли руками, а раз в неделю фронтенд отдавал пустые разделы: кэш не сбрасывался, и часть товаров выпадала из выдачи.

Что сделали

Контент перенесли в Cockpit CMS как headless-бэкенд: товары, категории и характеристики описали явными полями со связями, чтобы структура данных перестала зависеть от вёрстки. Витрину собирают статически, а по веб-хуку пересобираются только изменённые страницы — цена или описание обновляются без полного прогона.

Ручные операции остались там, где нужна редакторская проверка: импорт прайса сопоставляет позиции по идентификатору и сам подтягивает категории, а не просит разложить их заново. Вывод данных проверяется на этапе сборки — если у товара нет обязательного поля, страница не публикуется и пустой раздел не попадает на прод.

Метрики до и после: публикация — с 40 минут до 2, доля ручных операций — с почти 100% до единичных правок, отказы вывода — с 3–4 в неделю до нуля за квартал. Пересборку каталога теперь можно запускать в любой момент, не дожидаясь ночного окна.

Чем headless-бэкенд отличается от классической базы контента?

Классическая база контента держит хранение и вывод в одном контуре: страница собирается шаблонизатором самой системы, и разметка жёстко привязана к её движку. Добавить новый канал или сменить оформление — значит переписать шаблоны внутри. Headless-бэкенд разрывает эту связь: Cockpit CMS хранит структурированные записи и отдаёт их по запросу, а где и как их показать, решает фронтенд.

Разделение хранения и вывода — ключевая механика. Контент описывается коллекциями и полями: тексты, связи, медиа и локализации лежат как данные, а не как готовая разметка. Фронтенд на Next.js или Nuxt запрашивает нужный набор полей и собирает страницу сам, поэтому один материал без переписывания идёт и на сайт, и в приложение, и в отдельную витрину.

Для редактора меняется немного: он остаётся в привычной админке, но работает с полями вместо готовых страниц. Появляются черновики, отложенная публикация, версии и предпросмотр, а правка в одном месте расходится по всем каналам сразу. Согласование перестаёт упираться в вёрстку — контент-менеджер не ждёт разработчика, чтобы поправить текст.

Роль разработчика смещается от правки шаблонов к схемам данных и слою запросов. Он описывает коллекции, права на чтение и запись, кеш и сброс кеша, а фронтенд получает стабильный контракт. Обновление дизайна больше не трогает хранилище, а смена системы вывода не требует миграции контента.

Сомнения инженера: миграция, кэш, роли и права доступа

Сомнения на этапе выбора подрядчика касаются не самого редактора контента, а того, как он ведёт себя в эксплуатации: что будет с накопленной базой, как обновляется кэш, кто и что сможет править. Ниже — четыре вопроса, которые мы разбираем до старта, чтобы после запуска не пересобирать схему данных.

Что с кэшем страниц после правки контента?

Страницы отдаются из кэша, а при сохранении записи сбрасывается только связанная с ней разметка — остальной сайт продолжает отвечать быстро. Для крупных разделов настраиваем фоновое обновление, чтобы первый посетитель после публикации не ждал пересборки.

Как устроены роли и права доступа?

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

Что с внешними сервисами — аналитикой, формами, оплатой?

Бэкенд отдаёт данные по API, поэтому платёжные модули, формы и аналитика подключаются как отдельные сервисы, а не встраиваются в контент. Если внешний сервис недоступен, сайт продолжает работать: заявки уходят в очередь и отправляются повторно.

Обсудим задачу: входные данные и порядок оценки

Для оценки объёма работ по headless-бэкенду на Cockpit CMS достаточно тех входных данных, которые есть у вас уже сейчас — доступ к продакшену и подробный бриф на старте не нужны. Чем конкретнее вводные, тем точнее состав этапов и план внедрения: что попадает в первую поставку, а что разумно отложить на вторую.

• Схема контента или её набросок: какие коллекции нужны, какие поля в каждой, связи между ними, нужны ли черновики, версии и отложенная публикация.
• Макеты или прототип ключевых шаблонов: где данные приходят из API, где остаётся статика, какие блоки собираются из повторяемых компонентов.
• Список интеграций: формы, CRM, оплата, поиск, рассылки, аналитика — что должно получать данные от сайта и что отдавать в него.
• Роли и доступы: кто редактирует, кто только публикует, нужны ли мультиязычность и разные редакции контента под регионы.
• Ограничения: текущий хостинг и домены, требования к разметке для поиска, правила хранения персональных данных.
• Существующий код или API, если проект уже работает: доступ к репозиторию и тестовому контуру ускоряет разбор.
• Приоритеты по срокам: какая часть нужна к запуску, а какую можно вынести отдельным этапом без потери целостности.

На основе этого возвращаемся с оценкой объёма работ: разбивка по этапам, состав задач на вашей стороне, порядок выката и точки, где можно проверить результат до финальной сдачи. Если схема контента ещё не определена, предложим свой вариант структуры и покажем, как она ляжет на Next.js или Nuxt.

Опишите задачу — вернёмся с оценкой и планом работ.