Что такое headless Drupal?

Главные вкладки

gun_dose 9 июля 2017 в 18:05
6

атарвали галаву!
В последнее время идёт очень много разговоров о headless (иногда ещё его называют decoupled) Drupal. Давайте попробуем разобраться, что же это такое и какие преимущества это может нам дать. Headless означает "безголовый", т.е. друпалу просто взяли и зачем-то оторвали голову, как в том анекдоте про змею:

«- Давайте отрубим ей хлебало!
- Нет, давайте лучше отрубим ей хвост!
- Точно! По самое хлебало!»

Этот анекдот весьма уместен в нашем контексте, ибо в концепции headless Drupal под головой понимается именно то, что многие привыкли называть "мордой", т.е. весь слой темизации - сама тема и всё, что отвечает непосредственно за рендеринг html. Второе название этой концепции - decoupled - означает "разделённый", что подразумевает, то, что функции рендеринга где-то всё же выполняются, но не в друпале. В общем, в headless-системах Drupal отдаёт данные не в виде HTML-страниц, а посредством REST-сервисов в форматах JSON, XML, HAL и т.д. Основные кейсы применения такого подхода приблизительно следующие:

- когда доступ к контенту осуществляется посредством мобильных приложений;
- когда контент изначально предназначен для отправки в другую систему (автоматизированный обмен данными);
- когда нужно сделать обычный сайт;

Если с первыми двумя пунктами всё понятно, то третий наверняка у многих вызывает вопросы, ведь нормально же работали годами, а тут какой-то хэдлес появился. Типичный кейс, когда такой подход будет наиболее выигрышным - это сайт с обилием динамических элементов страниц и с большим количеством форм, например, соцсеть или CRM-система. Однако даже для простеньких бложиков такой подход может дать множество преимуществ, но об этом чуть позже, сперва давайте разберёмся, что нужно для построения такой системы. Возможно, вы уже догадались, что фронтенд и бэкенд в таком случае будут двумя совершенно раздельными приложениями. По сути, это два разных сайта, расположенных в разных доменах (субдоменах)

Backend

В качестве бэкенда необходимо взять Drupal 8. Ни в коем случае не 7, т.к. там глубина интеграции с REST-сервисами изначально не такая большая, как в восьмёрке. Достаточно включить модуль Rest, входящий в ядро, и уже можно получать, создавать, удалять через REST любые сущности, а также создавать вьюсы в формате REST-экспорта. Однако, "родной" формат, в котором Drupal 8 выдаёт JSON, изначально не совсем удобен для работы, поэтому я также рекомендую установить модуль JSONAPI, с ним вам даже не понадобится включать Views, но это отдельная история, заслуживающая целой публикации (которую я планирую написать в ближайшее время).

Frontend

В качестве фронтенда берём любой актуальный javascript-фреймворк, например React или Vue. Для тех, кто любит мастерить велосипеды и составлять картину мира из миллионов маленьких фрагментов, предпочтителен React, для тех же, кто привык следовать чётко выверенным инструкциям, лучше выбрать Vue. Глобально же никакой особой разницы нет.

Сервер

Если вы ленивый идиот начинающий разработчик и привыкли деплоить сайты по FTP, то вы сможете разместить свой сайт на любом хостинге, правда о сервер-сайд рендеринге (SSR) придётся забыть. Если же вы привыкли пользоваться системой контроля версий, то вам будет необходим как минимум виртуальный сервер, чтобы вы смогли установить на нём Node.js - это позволит вам собирать фронтенд-приложение из исходников прямо на сервере с учётом всех переменных окружения.

В итоге получается приблизительно так: в домене site.com располагается файл index.html, который также подгружает скрипты и стили. Сами же данные забираются с домена backend.site.com и отображаются в вашем фронтенд-приложении. Роутинг (обработка ссылок) при этом происходит не на сервере, а во фронетнд-приложении, это называется клиентский роутинг. Т.е. по сути вы загружаете одну единственную HTML-страницу, которая сама решает, как отображать нужные данные. Именно поэтому такие приложения часто называют SPA - Single Page Application (одностраничное приложение). Яркие примеры таких приложений - Facebook, Gitter, LinkedIn.

Зачем мне всё это?

Самая важная проблема, стоящая на пути освоения новых технологий - это мотивация. Я постараюсь вам её дать Smile Если в двух словах, то при построении сайтов по принципу headless Drupal + какой-нибудь современный js-фреймворк вы легко сможете делать сайты с реально крутым и быстрым интерфейсом. При этом для разработчика появляются следующие преимущества:

1. То, что раньше вы делали с помощью JQuery, теперь можно делать значительно быстрее. Ведь в JQuery для обработки какого-либо события приходилось отлавливать само событие и потом к нему цеплять логику обработки элементов страницы. С использованием современных фреймворков это не нужно, т.к. большинство из них поддерживают "реактивность" - это связанность отображения с данными. Т.е. если элемент выводит некий переменный текст, достаточно указать, что он выводит некую переменную, и затем, при обновлении значения переменной элемент перерисуется автоматически.

2. В разы ускоряется настройка самого друпала.
Если вы используете JSONAPI, то всё, что вам нужно - это создать необходимые типы контента и добавить им нужные поля. И всё! Не нужно настраивать отображение, не нужно делать вьюсы. Буквально полчаса настройки и можно переходить к проектированию фронтенда.

3. Больше не нужно устанавливать или писать самому модули для "украшательств". Больше не понадобится писать hook_form_alter, чтобы повесить на поле ".col-sm-3". Больше не надо мучаться с AJAX-коллбэками. Для динамических форм вам больше не нужен богомерзкий "#states".

4. Снижается нагрузка на сервер. При запросе данных через jsonapi часто происходит неполный бутстрап друпала, не вызываются функции темизации, не вызывается ничего лишнего, ведь при запросе ноды вы получите только ноду, а не кучу контента из хэдера, футера, сайдбаров, менюшек и т.д. А некоторые страницы фронтенд-приложение и вовсе сможет обрабатывать без запросов к серверу.

5. За этим будущее. Со временем люди забудут про спиннеры, перестанут пускать туман с запахом печенья, отнесут гироскутер на балкон или в подвал, но хайп вокруг SPA-приложений не утихнет ещё очень долго.

Я знаю, о чём вы сейчас подумали.

Действительно, если нам в друпале не нужно делать ничего, связанного с темизацией, то нам придётся сделать это в javascript. Однако, спешу вас заверить - это не так сложно, как кажется. Один из основных принципов разработки фронтенда на javascript - это использование готовых компонентов. Хотите галерею - вот вам готовая галерея, хотите графики строить - на выбор есть десятки компонентов разной степени навороченности, хотите всё сделать в стиле Material Design - получите полный сет стилизованных компонентов. Да, многие компоненты уже изначально поставляются со своими стилями, и бывает так, что на вёрстку практически не нужно тратить время. Кроме того, создавать собственные компоненты вовсе не сложно, равно как и совсем не сложно переопределить стили сторонних компонентов.

И традиционная ссылка на оригинал статьи в моём блоге

Автор

Комментарии

Аватар пользователя gun_dose gun_dose 9 июля 2017 в 22:10
1

Спасибо за ссылку, мне самому ни к чему, но читателям пригодится.)) Буду писать на эту тему ещё. Рад любым конструктивным обсуждениям в этом топике)) ты, кстати, сам то познал магию реакта? Сплешкину сборку для докера заюзал?)))

Аватар пользователя sas@drupal.org sas@drupal.org 10 июля 2017 в 9:21

А Вы не думали, что для MVC на бэкэ бустрее будет разрабытывать и гибче не на друпал 8 а например на symphony core, 8-ка то его юзает + много всего сделано в ней именно для "головы", отрубаем "голову", а туловиже то "жирное" и не уклюжее?!

Аватар пользователя gun_dose gun_dose 10 июля 2017 в 10:55
1

Симфони тоже не самый быстрый и гибкий. Да и вообще пхп далеко не лучший ЯП))) можно много философствовать, а можно работать

Аватар пользователя gun_dose gun_dose 10 июля 2017 в 22:30

Просто надо добавить связи, всё как обычно.

Но вообще, предпочтительнее использовать jsonapi. А вьюс только для сбора обратных референсов и агрегации.