Payload CMS 4: от CMS для Next.js к независимому контентному фреймворку

В Payload CMS 4 появилась поддержка TanStack Start и новый слой адаптеров для веб-фреймворков. Это одно из наиболее важных архитектурных изменений четвёртой версии: Payload начинает отделять собственное ядро от Next.js. В перспективе один и тот же проект сможет работать поверх разных веб-фреймворков без изменения конфигурации CMS.

Когда вышел Payload 3, одним из главных изменений стала тесная интеграция с Next.js.

Payload перестал выглядеть как отдельный сервер с CMS, к которому фронтенд обращается через REST или GraphQL. Его можно было установить непосредственно внутрь Next.js-приложения и использовать Local API, React Server Components и общую серверную инфраструктуру.

Это оказалось одним из сильных преимуществ Payload, но одновременно сформировало довольно жёсткую архитектурную связь с Next.js.

В Payload 4 команда начинает эту связь ослаблять.

В первой бета-версии появился новый механизм framework adapters, а первой альтернативой Next.js стал TanStack Start. Команда Payload прямо говорит, что долгосрочной целью никогда не была эксклюзивная поддержка Next.js. Мы уже писали о выходе первой беты, а здесь разбираем главное архитектурное изменение четвёртой версии подробнее.

Payload и раньше можно было использовать без Next.js

Здесь важно провести границу.

Payload — headless CMS, поэтому никто и раньше не запрещал сделать фронтенд на Astro, Vue, Nuxt, Svelte или вообще мобильное приложение.

Можно поднять Payload отдельно:

Payload
   │
   ├── REST API
   └── GraphQL API
          │
          ▼
      любой клиент

Например, один из участников свежего обсуждения Payload 4 пишет, что уже использует Payload вместе с Astro на рабочем сайте.

Но это не то же самое, что запустить сам Payload внутри другого фреймворка.

После выхода Payload 3 стандартная архитектура выглядит примерно так:

Next.js
│
├── сайт
│
├── Payload Admin
├── Payload API
├── React Server Components
└── Payload Local API
        │
        ▼
      database

Next.js здесь обслуживает не только публичный сайт. На его инфраструктуру опирается и сам Payload.

Поэтому вопрос «можно ли сделать фронтенд на Astro?» и вопрос «может ли Astro выполнять роль Next.js для самого Payload?» — совершенно разные вопросы.

Payload 4 начинает решать второй.

Framework Adapter

Чтобы поддерживать несколько фреймворков, разработчики Payload отделяют зависящие от конкретного фреймворка части от ядра.

Новый слой адаптеров отвечает в том числе за:

• отображение административной панели;
• React Server Components;
• загрузчики данных;
• подключение API к серверу.

То есть вместо предположения «Payload работает внутри Next.js» появляется абстракция:

Payload
                     │
             Framework Adapter
                     │
          ┌──────────┴──────────┐
          │                     │
       Next.js            TanStack Start

При этом сама конфигурация Payload остаётся той же.

Коллекции, поля, хуки, Access Control и другая прикладная логика не должны переписываться только потому, что приложение использует другой веб-фреймворк.

Именно это команда называет шагом к framework-agnostic Payload.

Первым стал TanStack Start

Первой альтернативной реализацией адаптера стал TanStack Start.

Это полнофункциональный React-фреймворк от команды TanStack, построенный вокруг TanStack Router и ориентированный на серверный рендеринг и типобезопасную разработку. К beta.2 адаптер перевели на стабильную версию самого TanStack Start, а команда опубликовала демо-репозиторий: административная панель Payload работает на TanStack Start и Vite, а рендеринг на React Server Components заменён на SSR и загрузчики данных маршрутов.

Для Payload он интересен не только как ещё один вариант технологического стека.

TanStack Start фактически служит проверкой самой архитектурной идеи.

Если Payload способен предоставить административную панель, API, серверные компоненты и остальные возможности поверх двух разных фреймворков, значит зависимость от Next.js действительно можно вынести за пределы ядра.

Поэтому значение поддержки TanStack гораздо шире количества разработчиков, которые прямо сейчас захотят перенести проект с Next.js.

Команда Payload называет её первым крупным этапом перехода к независимости от конкретного фреймворка.

И реакция сообщества довольно показательная. В обсуждении релиза разработчики спрашивают уже не столько про сам TanStack, сколько про то, появится ли аналогичная интеграция с Astro.

Пока поддержки Astro в качестве среды выполнения Payload нет. Но новая архитектура делает подобные адаптеры технически возможным направлением развития.

Зачем вообще было так тесно интегрироваться с Next.js

На первый взгляд история выглядит немного странно.

В Payload 3 CMS глубоко интегрировали в Next.js. Теперь в Payload 4 разработчики снова отделяют её от Next.js.

Но интеграция третьей версии дала Payload важное преимущество: CMS и приложение стали частью одного процесса.

На сервере можно получить данные напрямую:

const posts = await payload.find({
  collection: 'posts',
})

без HTTP-запроса к собственному REST API.

Это позволяет использовать общую типизацию, серверные компоненты и одну инфраструктуру приложения.

Адаптерная архитектура Payload 4 не отказывается от этой модели.

Меняется другое: веб-фреймворк перестаёт быть жёстко заданной частью архитектуры.

В идеале разработчик сохраняет преимущества embedded CMS, но получает возможность выбирать среду, в которой она работает.

Это принципиально отличается от возвращения к классической схеме «CMS отдельно, фронтенд отдельно».

Payload становится больше похож на платформу

Если смотреть только на поддержку TanStack, изменение может показаться нишевым.

Но оно хорошо сочетается с другими направлениями Payload 4.

В ядро переносятся иерархии документов. Они становятся общей примитивной структурой для папок, тегов, таксономий и древовидного контента. Со временем это должно заменить отдельный Nested Docs Plugin.

Серьёзно расширяется работа с файлами. В административной панели появляются крупные превью, сетка изображений, просмотр PDF и видео, сохранение оригинальных файлов и полноценное версионирование файлов вместе с документами.

Переработан MCP. Инструменты теперь включены по умолчанию, локальная разработка не требует отдельного API-ключа, а агентам можно задавать инструкции на уровне конкретной коллекции или глобальной настройки.

Наконец, полностью переработана административная панель.

Новая дизайн-система унифицирует цвета, типографику, отступы и другие элементы интерфейса. Появляется более масштабируемая боковая панель, а сама архитектура интерфейса должна упростить разработку собственных компонентов. Команда также работает над соответствием WCAG 2.2 AA к стабильному выпуску.

Все эти изменения движутся примерно в одном направлении.

Payload всё меньше похож на CMS, задача которой — дать разработчику несколько коллекций и REST API.

На его основе хотят строить административные системы, медиатеки, интернет-магазины, внутренние приложения и интерфейсы для ИИ-агентов.

Причём здесь Figma

Есть ещё один интересный контекст.

В официальном анонсе Payload прямо связывает переработку административной панели с использованием Payload в приложениях, создаваемых через Figma Make. Новая дизайн-система также основана на подходах Figma.

Это следствие сделки 2025 года, после которой Payload вошёл в Figma.

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

Его инфраструктура должна работать в гораздо более разнообразных приложениях.

Отсюда становятся понятнее и новая дизайн-система, и развитие управления файлами, и MCP, и стремление избавиться от обязательной зависимости от одного веб-фреймворка.

Это ещё не означает «Payload без React»

Здесь легко сделать слишком далеко идущий вывод.

Framework adapters не означают, что Payload 4 внезапно стал независим от всей React-экосистемы.

TanStack Start тоже работает с React. Административная панель Payload остаётся React-приложением, а в официальном описании framework adapter прямо упоминаются React Server Components.

Поэтому пока корректнее говорить об отделении от Next.js, а не об универсальной CMS, которую завтра можно встроить внутрь любого серверного фреймворка.

Нет и официально выпущенных адаптеров для Nuxt, SvelteKit или Astro.

Payload создаёт архитектурный слой, который делает дальнейшее расширение возможным. Насколько широкой станет поддержка, покажет развитие четвёртой версии.

А что будет с Next.js

Next.js никуда не исчезает.

Для существующих проектов он остаётся основным и наиболее зрелым способом запуска Payload.

Более того, параллельно с разработкой TanStack команда продолжает улучшать интеграцию с Next.js. Например, в недавней beta.3 появилась полноценная поддержка Cache Components.

Поэтому Payload 4 не стоит воспринимать как попытку уйти с Next.js.

Скорее меняется отношение между двумя проектами.

В Payload 3 архитектура фактически говорила:

Payload работает внутри Next.js

Новая модель ближе к:

Payload работает внутри поддерживаемого веб-фреймворка

а Next.js является одним из таких фреймворков.

Пока самым зрелым.

Почему это важно для разработчиков Payload

Для текущего проекта на Payload 3 архитектурное изменение само по себе ничего срочно не меняет.

Переписывать приложение на TanStack Start нет необходимости.

Но в долгосрочной перспективе это решает один из спорных моментов Payload 3: выбор CMS больше не должен автоматически означать выбор Next.js для всей серверной части приложения.

Например, команда может предпочитать TanStack Router и всю экосистему TanStack. Другому проекту потенциально может оказаться удобнее Astro. Через несколько лет может появиться ещё один популярный способ строить React-приложения.

Если слой адаптеров окажется удачным, Payload сможет развиваться независимо от этих изменений.

При этом прикладная часть проекта останется знакомой:

export const Posts: CollectionConfig = {
  slug: 'posts',

  fields: [
    {
      name: 'title',
      type: 'text',
      required: true,
    },
  ],
}

Коллекции не должны знать, какой именно фреймворк запускает административную панель и API.

И это, пожалуй, наиболее важная идея всей новой архитектуры.

Payload 4 пока остаётся бетой

Все эти изменения уже можно попробовать:

npx create-payload-app@beta

Но Payload 4 всё ещё находится в стадии beta — стабильная latest-ветка на npm остаётся на 3.x. Команда прямо предлагает разработчикам тестировать новую версию и сообщать о проблемах перед стабильным выпуском.

Поэтому использовать текущую реализацию TanStack Start как основание для срочной миграции рабочего проекта пока рано.

Гораздо интереснее воспринимать её как демонстрацию того, каким Payload хочет стать после четвёртой версии.

Что в итоге

Payload 3 показал, насколько удобной может быть CMS, встроенная непосредственно в современное веб-приложение.

Payload 4 пытается сохранить эту модель, убрав из неё обязательное условие — Next.js.

Первым результатом стала поддержка TanStack Start. За ней потенциально могут последовать другие адаптеры.

Вместе с новой административной панелью, иерархиями, расширенным управлением файлами и инструментами для ИИ-агентов это заметно меняет масштаб Payload.

Из headless CMS, глубоко интегрированной с Next.js, постепенно получается контентный фреймворк, который можно использовать как основу для разных типов приложений и, в перспективе, разных технологических стеков.

Именно это изменение выглядит гораздо важнее самого факта появления ещё одного поддерживаемого фреймворка.

Источники