Преамбула
Последние 5 лет набирают популярность так называемые Headless CMS. Если вкратце, это такие CMS, которые отвечают только за управление данными, но не за их вывод в виде сайта, как привыкли пользователи CMS.
Это классная идея, которая даёт свободу в выборе инструмента для вывода информации. Поэтому и количество вариантов реализации проекта возрастает на порядок.
Всё это здорово, если не увлекаться оверинженерингом, например, при создании простого сайта. Но призвание разработчика вынуждает оверинженерить в целях самообразования. А как иначе, если не отточить какой-то навык на простом проекте, применять его на сложном?
Мой опыт
Так и я недавно создал простой сайт-портфолио на стеке Next.js и MODX.
Next.js я использовал в качестве Frontend-а для сайта. Также я выбрал путь статической генерации (SSG), так как содержимое страниц не меняется в зависимости от того, кто заходит на страницу. Подробнее об SSG, SSR, CSR и ISR можно прочесть в другой моей статье.
А в качестве Headless CMS я использовал MODX 3.
Почему MODX?
Если ввести в поиске «headless cms», вы получите много ссылок на различные Headless CMS: Strapi, Ghost, Netlify CMS, Directus, Tina и так далее. Уверен, они стоят внимания, и они его получают: тысячи и десятки тысяч звёзд на гитхабе.
Но я выбрал MODX по следующим причинам:
- Я активно пользуюсь MODX c 2013, то есть более 10 лет.
- Я был сконцентрирован на изучении Next.js, и не хотелось распыляться на изучение ещё и новой CMS.
- Ввиду своего возраста MODX имеет огромное комьюнити, огромное количество оптимизированных решений и хороших практик.
- MODX не требователен к ресурсам и его можно поднять на любом хостинге с PHP в наличии (мой любимый хостинг — бегет).
Как используется 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
