Payload CMS или своя админка

Когда проект перестаёт быть обычным сайтом, довольно быстро возникает вопрос: а нужна ли здесь вообще CMS?

Допустим, мы делаем сервис. Пользователи регистрируются, создают какие-то сущности, загружают фотографии и документы. Сотрудники проверяют заявки, меняют статусы, что-то публикуют. Есть роли и права доступа. Данные используются одновременно сайтом, мобильным приложением и, возможно, другими сервисами.

В этот момент легко решить, что CMS здесь уже не подходит и пора писать собственный backend с собственной админкой.

С Payload граница не такая очевидная.

Админка — только часть Payload

Если смотреть на Payload как на панель для редактирования страниц сайта, то для приложения он действительно кажется лишним.

Но Payload — это ещё и вполне нормальный backend приложения.

Описываем коллекцию:

export const Applications: CollectionConfig = {
  slug: 'applications',
  fields: [
    {
      name: 'title',
      type: 'text',
      required: true,
    },
    {
      name: 'status',
      type: 'select',
      options: ['draft', 'moderation', 'published'],
    },
    {
      name: 'author',
      type: 'relationship',
      relationTo: 'users',
    },
  ],
}

И вместе с ней получаем REST и GraphQL API, административный интерфейс, валидацию, права доступа, хуки и работу с базой.

То есть значительную часть скучного backend-кода писать уже не приходится.

Например, сервис с пользовательским контентом

Представим приложение, в котором пользователь создаёт заявку.

У заявки есть автор, описание, фотографии, статус модерации и дата публикации. Пользователь видит только свои заявки. Модератор — ожидающие проверки. Администратор — всё.

Для этого в Payload вполне естественно завести users, applications и media.

Дальше настроить access control:

access: {
  read: ({ req }) => {
    if (req.user?.role === 'admin') return true

    return {
      author: {
        equals: req.user?.id,
      },
    }
  },
}

Добавить хуки на смену статусов, ограничения на загрузку файлов и необходимые действия в админке.

Сайт при этом вообще не обязан использовать административный интерфейс Payload. Он работает с API. Мобильное приложение — с тем же API.

Payload здесь фактически становится backend-фреймворком с готовой админкой.

Но бизнес-логику он за вас не напишет

Вот здесь проходит более полезная граница.

Допустим, в нашем сервисе появляются платежи.

Сам платёж можно связать с коллекцией Payload. Можно хранить его статус, пользователя, сумму, идентификатор транзакции.

Но правила вроде:

если платёж подтверждён, заявка прошла модерацию, лимит пользователя не превышен и договор действителен — выполнить действие X

— это уже логика приложения.

Её всё равно придётся проектировать и писать.

То же самое касается сложного биллинга, расчётов, интеграций с внешними системами, очередей, фоновых процессов и других вещей, специфичных именно для вашего продукта.

Не стоит пытаться превращать каждую такую операцию в очередной CMS-hook только потому, что Payload уже подключён.

Тогда зачем здесь Payload?

Чтобы не писать всё остальное.

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

Каждая из этих задач сама по себе не выглядит страшной.

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

Если Payload закрывает этот слой, его можно оставить Payload.

А свою разработку потратить на ту часть системы, ради которой приложение вообще существует.

Когда я бы писал своё

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

В таком проекте собственный backend может оказаться проще.

Но аргумент «у нас уже не сайт, а настоящее приложение» сам по себе недостаточен.

Payload не обязательно должен быть CMS всего проекта.

Он вполне может быть той частью backend-а, которую не пришлось писать самим.