Почему в контентной системе Notion удобен как пространство мышления и черновиков, а Directus — как структурированный слой данных, API и будущих интеграций.
Долгое время я искал одну CMS, которая решит всё. Пробовал Notion как единственный источник данных для сайта. Потом смотрел на Strapi, потом на Directus. Каждый раз думал: ну вот, сейчас найду правильный инструмент — и больше не придётся ничего менять.
Вместо этого пришёл к другой модели: у разных слоёв контентной системы разные роли. И когда каждый инструмент делает то, что у него получается лучше всего, система работает спокойнее.
Notion удобен для работы с контентом по одной причине: в нём удобно думать.
Открыл страницу, набросал структуру, переставил блоки, добавил комментарий для себя, посмотрел на текст целиком. Передал агенту ссылку на черновик — и агент работает в том же пространстве, где работаете вы.
Контент рождается в живом пространстве, где можно менять мысль на лету. Notion — именно такое пространство.
Здесь живут черновики, редакционные статусы, теги, обложки, внутренние комментарии. Здесь автор и ИИ-агент работают в одном интерфейсе. Для редакционного процесса это важнее, чем техническая чистота.
У Notion есть потолок.
Пока сайт маленький и данные забирает один билд через API — всё работает. Стоит добавить второй сайт, внешние интеграции, агентов, которые пишут данные обратно, preview-режим, права доступа для разных ролей — и Notion начинает трещать.
Потому что его роль — быть пространством мышления. А для production-слоя нужен инструмент, который говорит на языке структуры: поля, типы, валидация, API, роли, вебхуки.
Здесь появляется Directus.
Directus — headless CMS с открытым кодом, которая работает поверх вашей базы данных. Directus не пытается быть редактором. Зато хорош как производственная система.
В нём живут:
Когда контент из Notion переезжает в Directus, он превращается из черновика в управляемую сущность. У него появляются чёткие поля, статусы, версии, точки интеграции.
Astro собирает публичный сайт из данных, которые отдаёт production-слой.
Это static site generator: на этапе билда забирает контент через API и генерирует HTML-страницы. Быстрые, SEO-friendly, независимые от состояния сервера в момент запроса.
Когда я переносил pimenov.ru с Тильды на свою систему, именно Astro стал публичной поверхностью. Он не хранит данные, не редактирует контент, не знает про черновики. Его работа — превратить структурированные данные в сайт.
Вот формула, которая сейчас работает на pimenov.ai:
Notion — редакционный мозг. Здесь рождаются черновики, работают агенты, живёт редакционный процесс.
Directus — производственный слой. Здесь контент структурирован, типизирован, доступен через API.
Astro — публичная поверхность. Быстрый статический сайт, который читатель видит в браузере.
Контентный граф — карта смыслов. Показывает связи между материалами, пробелы, маршруты к услугам.
Агенты — помощники между слоями. Забирают сырьё из инбокса, пишут черновики, проверяют связи, синхронизируют данные.
Каждый элемент делает своё дело. Ни один не пытается заменить остальные.
Когда всё живёт в одном инструменте, любая проблема ломает весь процесс. API Notion упал — сайт не билдится. Нужен preview — приходится городить обходные пути. Нужны права для внешнего редактора — делиться всей базой.
Когда роли разделены, сбой в одном слое не роняет остальные. Notion может быть недоступен — сайт продолжает работать, потому что данные уже в Directus. Directus обновляется — черновики в Notion это не затрагивает.
Разделение ответственности делает каждый шаг предсказуемым.
Если у вас один сайт и десять статей — архитектура ролей вам пока ни к чему. Notion плюс Astro достаточно.
Но если контента становится много, появляются агенты, нужны API для внешних сервисов, сайт начинает обрастать функциями — стоит подумать про отдельный production-слой.
Мне помогло перестать искать идеальный инструмент и вместо этого честно назвать роли. Когда каждый элемент системы знает, за что отвечает, работать с контентом становится спокойнее.
Если вы думаете над контентной архитектурой для своего проекта и хотите разобраться, как разложить роли между инструментами — стоит обсудить.
Если захотите обсудить, как это применить у себя или в команде — пишите в Telegram @pimenov