Разделенный decoupled, headless Drupal

Сейчас требования бизнеса к реализации веб-приложений значительно изменились. Зачастую создания простого сайта или веб-приложения с фиксированным источником потребления данных уже недостаточно. Количество каналов, которым нужны данные приложения, стремительно расширяется — от мобильных телефонов, часов, компьютеров, других различных устройств до систем, предназначенных только для внутреннего использования бизнесом, а также чатов и социальных сетей. Все чаще заказнику нужен не просто сайт, а полноценное приложение, которое будет работать на нескольких видах устройств, будет доступно везде, реализует сложную логику обработки введенных пользователем данных, будет иметь широкие возможности для кастомизации и поддерживать максимальное количество современных технологий. Понимая это, разработчики Drupal при создании 8 версии начали закладывать в систему принцип API-first для реализации разделенного Drupal. Выход новой девятой версии Drupal в 2020 году только закрепил архитектуру, ориентированную на API, а также включил в ядро модуль JSON — API, который позволяет создавать надежные независимые и автономные приложения. Данная статья будет первой в цикле статей о разделенном Drupal.

Так что же означает decouple или headless Drupal? Термин decouple в переводе с английского значит “разделенный”, то есть то, что Drupal разделен, и от него отделена та часть, которая отвечает за формирование и вывод информации пользователю. Термин headless буквально означает “без лица”. Лицом (“веб-мордой”) принято называть веб-интерфейс — то, что видит пользователь и с помощью чего он взаимодействует с приложением. Можно сказать что разделенный Drupal — это Drupal, из которого убрана часть, отвечающая за формирование и вывод пользовательского интерфейса, это весь слой тем Drupal (темы сайта, хуки препроцесса, функции рендеринга и прочие составляющие Theme API). При данном подходе Drupal отдает не готовую страницу в виде html-кода, а использует REST-сервис для генерации ответа пользователю в форматах JSON, HAL, XML. Данный подход используется в таких случаях:

• при создании сайтов с большим количеством форм и динамическим веб-интерфейсом, сайтов, которые активно взаимодействуют с пользователями (соцсети, CRM системы, чаты и т.п.);
• для совместной работы или обмена данными с другими веб-сервисами;
• для использования Drupal как бэкенда для мобильных приложений;
• для разработки различных веб-приложений со сложной логикой обработки пользовательских данных;
• во многих других случаях, когда нужно организовать надежную систему для создания и хранения данных и управления ими с возможностью получать информацию любыми источниками потребления этих данных.

• Снижается нагрузка на веб-сервер. Так как не используется слой тем, происходит неполная загрузка Drupal: запускается только то, что требуется для выдачи данных в необходимом формате. Это позволяет экономить немало ресурсов веб-сервера, некоторые страницы могут обрабатываться вообще без его участия.
• Ускоряется разработка стандартного веб-приложения со стороны бэкенда. Все что нужно — это создать необходимые сущности (типы контента) с нужными полями, настроить связи между ними, организовать роли пользователей, правила контроля доступа и все, можно начинать разработку фронтенда с помощью любого выбранного вами фреймворка — react, vue, angular, ember.
• Выбор на стороне фронтенда популярных библиотек. Современный javascript-инструментарий обеспечит вас высокой скоростью и надежностью разработки пользовательских интерфейсов, вы получите доступ к сотням их готовых компонентов, ощутите все плюсы реактивности, перестанете создавать сотни шаблонов на стороне Drupal, избавитесь от JQuery спагетти-кода, не станете создавать отдельный шаблон или preprocess функции, альтерить формы только для того, чтобы добавить всего один класс к полю.
• Вариативность в выборе разработчиков. В последние годы опыт разработчиков также стал важным фактором. Тот факт, что теперь существует несколько способов написания интерфейсов для Drupal, упрощает поиск людей для работы над проектами. Например, многим компаниям трудно найти специалистов, имеющих опыт работы с Twig, но в то же время на рынке много js-разработчиков. Переход на интерфейс на основе JavaScript может решить проблемы с человеческими ресурсами.

Существует три наиболее распространенных подхода к архитектуре Drupal с точки зрения его разделения: традиционный (связанный), частичное разделение и полное разделение. Варианты разделения Drupal обусловлены различными предпочтениями и требованиями.

В традиционном подходе все обычные функции Drupal остаются неизменными: Drupal остается монолитной системой и дает полный контроль над уровнями представлений и данных. Традиционный Drupal остается отличным выбором для ситуаций, когда редактору нужен полный контроль над визуальными элементами с доступом к быстрому редактированию и управлению компоновкой элементов на странице. Это тот Drupal, каким мы его знали все время. Поскольку преимущества данного подхода очевидны, именно на нем основывается большинство новых проектов, связанных с управлением контентом.

Иногда для обеспечения интерактивного взаимодействия с пользователем требуется использовать JavaScript. В этом случае требуется несвязанный подход. В частично разделенном Drupal фреймворк или библиотека JavaScript накладывается поверх существующего внешнего интерфейса Drupal. Этот JavaScript может нести ответственность за рендеринг как одного блока или компонента на странице, так и может отображать все, что находится в теле страницы. Суть частичного разделения лежит в том, что чем меньше страница управляется JavaScript, тем больше редакторы могут управлять ей с помощью административных возможностей Drupal.

До недавнего времени полностью развязанный Drupal был единственной категорией несвязанной архитектуры Drupal, которая отражала полное разделение задач между уровнем представления и всеми другими аспектами CMS. В этом сценарии CMS становится поставщиком данных, а приложение JavaScript с рендерингом на стороне сервера (или клиента) становится ответственным за генерацию страницы, взаимодействуя с Drupal через API веб-сервисов. Хотя ключевые функции — редактирование на месте (режим быстрого редактирования) и управление компоновкой элементов — недоступны для редакторов, полностью разделенный Drupal привлекает разработчиков, которым нужен больший контроль над интерфейсом и имеющих опыт создания приложений в фреймворках и библиотеках Angular, React, Vue.js и т. п.

В последнее время в полностью развязанном Drupal добавилась еще одна парадигма. JAMstack (JavaScript, API, Markup) представляет новый подход — полностью отделенные статические сайты. Основная причина создания именно статических сайтов — повышение производительности, безопасности и упрощение для разработчиков. Генератор статических сайтов, такой как Gatsby, будет извлекать контент из Drupal, генерировать статический веб-сайт и разворачивать этот статический сайт в CDN.

Чтобы определиться, какой Drupal вам нужен — разделенный или нет, задайте вопрос, что вы хотите получить в итоге. Дрис Бёйтарт (основатель и руководитель проекта Drupal) в своей статье про разделенный Drupal дает следующие советы:

1. Если вы намерены создать единый автономный сайт или приложение, выбор неразделенного (монолитного) или раздельного Drupal зависит от того, какие функции для вас являются обязательными и приоритетными — направленные на редакторов или на разработчиков.
2. Если вы намерены создать несколько веб-интерфейсов (сайты или приложения) на основе одного репозитория данных, можно использовать разделенный Drupal либо как а) репозиторий (хранилище) контента без собственного общедоступного интерфейса, б) традиционный сайт, который одновременно служит для управления данными и хранения контента для других интерфейсов. В зависимости от того, насколько динамичным должно быть ваше приложение, вы можете выбрать библиотеки и фреймворки JavaScript для более интерактивных сайтов или генераторы статических сайтов для менее динамических сайтов
3. Если вы хотите создать несколько не веб-ориентированных интерфейсов (например, нативные мобильные приложения или приложения для “интернета вещей”), можете использовать полностью разделенный подход, чтобы предоставить пользователю API веб-сервисов и использовать Drupal только для управления данными и их хранения без собственного общедоступного интерфейса.

Что делает Drupal таким мощным, так это то, что он поддерживает все эти варианты использования. Drupal упрощает реализацию несвязанного (разделенного) приложения благодаря широко признанным стандартам, таким как JSON: API, GraphQL, и OpenAPI. В конце концов, именно ваши технические требования решат, будет ли разделенный Drupal вашим следующим выбором. Помимо технических требований, часто играют роль организационные факторы. Например, если сложно найти фронтенд-разработчиков Drupal со знанием Twig, возможно, имеет смысл нанять более доступных разработчиков на JavaScript и создать полностью независимую реализацию. Наиболее важным аспектом любого решения, когда дело доходит до разделения Drupal, является список функций, необходимых вашему проекту; нужно тщательно учитывать потребности редакторов и разработчиков. Важный шаг в процессе оценки — взвешивание различных преимуществ и недостатков. Каждый проект должен начинаться с ясной оценки того, что необходимо для его реализации и что нужно получить в итоге. Drupal продолжает оставаться идеальной CMS для несвязанных архитектур, это отличный выбор для традиционных и разделенных подходов с функциями, которые выходят далеко за рамки конкурентов Drupal — WordPress, Sitecore и Adobe. Независимо от того, какой выбор сделаете, какое приложение решите реализовать, у Drupal всегда есть решение для вас. В следующих статьях мы рассмотрим стандартный функционал Drupal 9 для создания decoule-приложений и создадим headless-приложение с Drupal на стороне бэкенда и Vue.js на стороне фронтенда.