Привет .
Меня зовут Михаил, более 10 лет разрабатываю интернет-проекты: от сайтов до систем автоматизации.

Преамбула

Последние 5 лет набирают популярность так называемые Headless CMS. Если вкратце, это такие CMS, которые отвечают только за управление данными, но не за их вывод в виде сайта, как привыкли пользователи CMS.

Это классная идея, которая даёт свободу в выборе инструмента для вывода информации. Поэтому и количество вариантов реализации проекта возрастает на порядок.

Всё это здорово, если не увлекаться оверинженерингом, например, при создании простого сайта. Но призвание разработчика вынуждает оверинженерить в целях самообразования. А как иначе, если не отточить какой-то навык на простом проекте, применять его на сложном?

Мой опыт

Так и я недавно создал простой сайт-портфолио на стеке Next.js и MODX.

Next.js я использовал в качестве Frontend-а для сайта. Также я выбрал путь статической генерации, так как содержимое страниц не меняется в зависимости от того, кто заходит на страницу.

А в качестве Headless CMS я использовал MODX 3.

Почему MODX?

Если ввести в поиске «headless cms», вы получите много ссылок на различные Headless CMS: Strapi, Ghost, Netlify CMS, Directus, Tina и так далее. Уверен, они стоят внимания, и они его получают: тысячи и десятки тысяч звёзд на гитхабе.

Но я выбрал MODX по следующим причинам:

  1. Я активно пользуюсь MODX c 2013, то есть более 8 лет.
  2. Я был сконцентрирован на изучении Next.js, и не хотелось распыляться.
  3. Ввиду своего возраста MODX имеет огромное комьюнити, огромное количество оптимизированных решений и хороших практик.
  4. MODX не требователен к ресурсам и его можно поднять даже на самом простом хостинге.

Как используется MODX?

1 Установка MODX и дополнений

Для разработки проекта мне понадобились следующие дополнения:

  • Collections — для более удобного редактирования больших коллекций ресурсов.
  • Ace — редактор кода.
  • CKEditor — WYSIWYG-редактор ресурсов.
  • translit — для транслитерации URL ресурса на основе заголовка ресурса.
  • filetranslit — для транслитерации имени файла при загрузке.

2 Создаются ресурсы для контента

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

3 Создаются ресурсы для API

Ресурсы я создаю с Content-Type равным application/json. Также в настройках системы убираю расширение .json, чтобы итоговый эндпоинт выглядел так: https://example.com/api/articles.

Далее на каждом эндпоинте нужно вызвать сниппет, который вернёт данные в нужном формате (обычно JSON). Для выборки я использую встроенную ORM: xPDO. Она прожорливая, но для простых сайтов это не ощущается, в крайнем случае есть простор для оптимизаций (например, использование более нативных средств).

Как работает Frontend?

При сборке проекта происходят API-запросы, и на основе полученных данных создаются статические страницы.

Ну а дальше происходит деплой сайта, например, через Vercel.

Можно пример?

Можно: https://quasi-art.ru/portfolio/webdev/artist-portfolio-website