Admingen — генератор Headless CMS: он создаёт Go backend, React-систему администрирования и REST API по модели проекта. Клиентский сайт выбирает способ получения контента отдельно: через external API или из подготовленного снимка данных.
Для нового лендинга и документации в admingen-landing выбран JSON-снимок в репозитории сайта. Это решение относится к этому сайту, а не ограничивает возможности генерируемых приложений. Административные токены и параметры доступа к БД в сайт не переносятся.
Что входит в снимок документации
Источник статей — документационные записи локальной CMS: DocSection задаёт разделы, DocArticle — статьи. В снимок входят раздел, slug, заголовок, описание, Markdown-текст, порядок, язык и версия контракта. Существующие slug сохраняются, чтобы ссылки на статьи оставались узнаваемыми.
В документации шесть разделов: Начать, UI интерфейс, Концепции, CLI интерфейс, Эксплуатация, О проекте. Публичный снимок включает только опубликованные статьи. Пользователи, авторизационные данные, секреты и другие таблицы приложения не экспортируются.
JSON — содержимое для отображения. Он не изменяет модель CMS, работающую БД или правила API.
Как обновляется сайт
- Измените статью в DocArticle или обновите соответствующий документационный источник проекта.
- Сохраните прежний slug, если адрес статьи должен остаться тем же.
- Подготовьте актуальный документационный JSON-снимок и проверьте его содержание.
- Обновите сайт обычным процессом сборки и выпуска.
Сохранение записи в CMS само по себе не обновляет JSON, уже выпущенный вместе с сайтом. Для этого нужен новый снимок и выпуск сайта. Изменение текста записи не требует Generate в CMS; изменение структуры CMS или правил её API требует Generate и соответствующего выпуска backend.
Страница статьи и навигация
Каталог строится из разделов и метаданных статей. Открытая статья отображает Markdown-текст; оглавление выводится из заголовков статьи. Поиск и переходы в JSON-версии используют сохранённое содержимое снимка.
Ссылки вида /docs/<slug> обозначают статьи внутри документации. При размещении документации на отдельном домене адреса клиента и обработку прямого открытия маршрута нужно настроить в конфигурации сайта. JSON-снимок не создаёт DNS, сервер или сертификаты.
В Markdown встречаются обозначения screenshot:<ключ>. Они указывают место для иллюстрации, а не готовый адрес картинки. Клиент должен сопоставить ключ реальному изображению либо показать подписанное место под скриншот; выдуманную картинку продукта подставлять не нужно.
Если вашему сайту нужен живой CMS API
Генерируемый external API остаётся отдельным поддержанным способом доставки контента. Разрешите нужные операции и задайте обязательные условия чтения в Generator UI → настройки сущности → Access. Например, status = published ограничивает выдачу опубликованными записями. Виртуальные сущности и вложенные коллекции имеют собственные правила; правила исходных сущностей автоматически не наследуются.
Публичный Nginx-кэш, если вы его явно включили, применяется к анонимным external List/Get. Запись данных не сбрасывает его автоматически; прежний ответ может сохраняться до истечения TTL. Для статического JSON-снимка это не механизм обновления: его содержимое меняется только после обновления самого файла и выпуска сайта.
Для живого клиента используйте контракт API. Настройки доступа описаны в Content / Access, кэш и подключение — в скорости API.