Вы здесь

Будущее отвязанного Друпала

Из всех трендов в сообществе Паутины, не многие распространяются быстрее чем отвязанные (decoupled/headless — бэк-энд отвязанный от фронт-энда) системы управления содержанием. Эволюция от сайтов к более интерактивным веб-приложениям и необходимость мультиканальных публикаций предполагает, что отвязанная архитектура использующая в качестве рычага клиентские фрейм-ворки является следующим логическим шагом для Друпала. В этой статье, термин «отвязанный» подразумевает разделение между бэк-эндом и фронт-эндами, вместо традиционной сервис-ориентрированной архитектуры.

The future of decoupled Drupal

Традиционная (монолитная, связанная) парадигма архитектуры против отвязанной

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

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

Тем не менее, важно умерить шумиху вокруг отвязанного управления содержанием сделав сбалансированный анализ. Перед отвязыванием нужно спросить себя, готовы ли вы работать без возможностей, которые обычно предоставляются CMS — такими как макеты и управление показом, предпросмотром содержания, локализацией интерфейса, показом форм, доступностью для инвалидов, идентификацией, критическими вопросами безопасности (таким как XSS и CSRF) и быстродействием. Многие из них должны быть переписаны с нуля или не смогут быть реализованы вообще на стороне клиента. Для многих проектов, создание отвязанных приложений или сайтов поверх CMS приведёт к потере важных функций или резкому росту стоимости переделки потерянных возможностей.

Для ясности. Я не против отвязанных архитектур как таковых. Скорее я думаю, что отвязка должна быть мотивирована. Так как эволюция такой парадигмы архитектуры ещё молода, нам нужно осознать как и в каких сценариях мы отвязываемся. В этой статье мы рассмотрим различные архитектуры отвязывания, обсудим почему полностью отвязанная архитектура это не идеальный вариант для всех случаев использования и представим «прогрессивную отвязку» — лучший подход к которому готов в Друпал 8. Сегодня Друпал 8 готов доставлять страницы быстро и предлагает разработчикам гибкость в реализации взаимодействия с сайтом пользователя через отвязывание интерактивных компонентов.

Полная отвязка это обычно не лучшее решение

The future of decoupled Drupal

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

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

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

Используя Друпал для создания сайта с содержанием разных типов, чтобы доставить обзоры на музыку, очень просто сделать такой сайт используя типы содержания и возможности редактирования. Мы можем перечислить, классифицировать и написать обзоры используя интерфейс Друпала. Но так как Друпал выполняет рендеринг на стороне сервера, а не на стороне клиента, Друпал не удовлетворяет предполагаемой работе пользователя на сайте. Тем временем, имеющиеся JavaScript MVC фрейм-ворки и фрейм-ворки создания приложений плохо подходят для управления большим количеством содержания, из-за необходимости перестроения инструментов управления содержанием и создания сайтов, и они платят за это быстродействием.

В полностью отвязанной архитектуре наши потери от необходимости перестроения того, что Друпал даём нам без труда, перевешивают преимущества от фрейм-ворков работающих на стороне клиента. С полностью отвязанным фронт-эндом мы потеряем важные аспекты слоя темизации (которые тесно переплетаются с API Друпала), такие как систему хуков темизации, шаблонизации Twig и в разной степени конвейер рендеринга. Мы потеряем предпросмотр содержания и нюансы связанные с созданием, модерацией и составлением содержания, инструменты управления макетом. Мы потеряем все преимущества доступности и удобства, которые делают сайты на Друпале 8 удобными как для пользователей, так и для веб-мастеров, таких как роли ARIA, улучшенная система сообщений и что наиболее заметно, панели инструментов интегрированные на страницы не относящиеся к страницам управления сайтом. Кроме того, там где есть сложная интерактивность, там легко внедрить разные угрозы безопасности.

Прогрессивный рендеринг с BigPipe

Полностью отвязанная архитектура может иметь также недостатки связанные с быстродействием. Мы хотим, чтобы пользователь увидел информацию как можно быстрее (время появления) и как можно быстрее мог выполнить желаемое действие (время взаимодействия). CMS с хорошей архитектурой здесь будет иметь преимущество перед фрейм-ворком работающем на стороне клиента.

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

То, что нам действительно здесь нужно, это инструмент выборочной обработки компонентов и отправка простых частей перед отправкой сложных. С BigPipe, подходом подставляющим динамическое содержание на стороне клиента, мы можем выполнять рендеринг наших страниц прогрессивно, сначала загружать скелет страницы, а затем долгообрабатываемые компоненты, такие как «песни, которые я слушал чаще всего на прошлой неделе» или «то, что я слушаю в настоящее время». То, что рендерится быстро, отправляется сразу вместе с заполнителями, которые потом подменяются уже рассчитанными сложными частями.

В настоящее время Друпал 8 является единственной CMS, в которой BigPipe глубоко интегрирован по всем направлениям с ядром и дополнительными модулями — они просто должны предоставить некоторые мета-данные для кеширования и не нуждаются в подробном описании технических мелочей. Модуль Internal Dynamic Page Cache убеждается, что скелет страницы уже закеширован и может отправить его сразу. Например, меню одинаковы для многих пользователей, поэтому мы можем использовать повторно эти меня для тех пользователей, которые хотят получить доступ к их ссылкам, поэтому Internal Dynamic Page Cache может включить их в кеш скелета страницы. С другой стороны, персонализированный блок с данными о самых прослушиваемых пользователем песнях не эффективен для кеширования и поэтому он рендерится после отправки скелета страницы. Эта кешируемость встроена в ядро и каждый дополнительный модуль может предоставить необходимые мета-данные для работы с ней.

Чтобы полностью отвязанный сайт загружался быстрее, чем сильно персонализированный сайт на Друпале 8 использующий BigPipe, нужно будет переработать много логики интеллектуального кеширования, хранить кеш на стороне клиента и непрерывно синхронизировать кеш клиента с данными сервера. Кроме того, разбор и выполнение яваскрипта для генерация HTML занимает больше времени чем простое скачивание HTML, особенно на мобильных устройствах. В результате, потребуется крайне хорошо оптимизированный яваскрипт, чтобы справиться с этой проблемой.

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

Будущее за прогрессивной отвязкой

The future of decoupled Drupal

При прогрессивной отвязке CMS продолжает выполнять рендеринг скелета страницы.

Как мы видим, полная отвязка устраняет критически важные возможности CMS и BigPipe в области рендеринга. Но что, если бы мы могли отвязаться продолжая иметь оба преимущества? Что, если мы сохраним такие вещи как управление макетом, безопасность и доступность вместе с отвязкой, сохранив при этом все преимущества взаимодействия со страницей приложения? Ещё важнее, что если если мы можем получить преимущества BigPipe, чтобы сократить время взаимодействия и убрать препятствия удлиняющие показ сильно персонализированного содержания? Ответ лежит в отвязывании компонентов или прогрессивной отвязке. Вместо отвязки всей страницы целиком, почему не отвязать только части страницы, такие как отдельные блоки?

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

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

Друпал 8 опережает конкурентов и является хорошей платформой для создания отвязанных сайтов. Он распространяется с встроенным REST API для всего содержания, системой запроса данных из Друпала (например экспорт REST в модуле Views) и BigPipe. Он будет ещё лучше с полным набором дополнительных модулей по работе с REST.

С Друпалом 8 открывается захватывающий спектр возможностей, потому что Друпал позволяет избежать двух крайностей — традиционный подход и подход с полной отвязкой. Как мы видим, полная отвязка открывает дверь для работы с Друпалом одного или нескольких клиентов («многоголовый» Друпал), таких как мобильные приложения, интерактивные киоски и телевизоры. Но прогрессивная отвязка идёт дальше, потому что мы можем полностью отвязать и прогрессивно отвязать один сайт на Друпале с полным набором инструментов не тронув те части, которые не хотим.

Что дальше с отвязкой в Друпале?

The future of decoupled Drupal

В случае многоголового Друпала, полностью отвязанные приложения могут жить вместе с прогрессивно отвязанными страницами, скелеты которых рендерятся CMS.

Несмотря на то, что Друпал добился в последние несколько лет больших успехов и опережает конкурентов, нам есть над чем работать. Традиционный Друпал, полностью отвязанный Друпал и прогрессивно отвязанный Друпал могут сосуществовать. Используя улучшенные инструменты отвязки, Друпал может стать ещё лучшим хабом для многих голов: коллекции приложений и сайтов, связанных и поддерживаемых через один бэк-энд.

Один из самых сложных вопросов стоящих перед разработчиками фронт-энда — быстродействие сети с REST. Например, запрос REST получает несколько объектов содержания, требующих кругового обхода сервера для каждого отдельного объекта, каждый из которых может быть завязан на связанные данные, такие как связанные с ним объекты, требующие отдельных запросов к серверу. Затем, чтобы получить требуемые данные, каждый запрос REST нуждается в отправке на бэк-энд бутстрапа, что может создавать довольно большую нагрузку. Такой большой стек круговых опросов и бутстрапов может быть слишком дорогостоящим в обработке.

В настоящее время, единственным способом решить эту проблему является создание точек API (например в Views), которые в совокупности предоставляют клиенту все необходимые данные в одном ответе, чтобы минимизировать круговые проходы. Но управление этими точками для каждого клиента может быстро выйти из-под контроля, так как клиент может требовать широкий диапазон различной информации. С другой стороны, если вы завязаны на одну точку, обновление потребует изменения всего яваскрипта, который связан с этой точкой и использует её ответ. Вопросы с управлением этими точками могут поставить разработчика фронт-энда в зависимость от работы разработчика бэк-энда, что создаёт узкие места в отвязанных группах разработчиков.

Кроме быстродействия и управления точками, разработчики также могут зависеть от отвязанной архитектуры RESTfull. Для каждого отдельного запроса есть одна схема неизменного ответа. Чтобы получать различно отформатированные данные или фильтрованные данные под свои нужды, нужно создать второй вариант этой точки или сделать новую точку целиком. Разработчики фронт-энда, беспокоящиеся об ограничении быстродействия, желают получить полный контроль со стороны клиента над тем, какая схема возвращается и хотят избежать работы с серверной стороной.

Таким образом, отвязка выявляет необходимость лучших способов экспонирования данных на сторону клиента. Так как наши страницы и приложения становятся всё более компонентными, нам будет нужно выполнять всё более сложные запросы, и наши требования к быстродействию этих задач возрастут. Что, если бы мы могли извлечь только те данные, которые нам нужны с помощью такого запроса, который прост и быстр по умолчанию? Себастьян Симсен предлагает использовать Facebook GraphQL (смотрите демонстрационное видео и дополнительный модуль) из-за явного определения того, какая схема должна быть возвращена клиенту и использования объединённых запросов, которые разбиваются на маленькие вызовы и рекомбинируются для ответа, сводя к минимуму круговые обходы.

Мне нравится подход GraphQL как в случае полной, так и в случае прогрессивной отвязки фронт-энда. Он означает, что отвязанные сайты будут обладать лучшим быстродействием в целом и фронт-энд разработчику будет удобнее работать: небольшое количество походов на сервер, не нужны свои точки, не нужно версионирование, нет зависимости от разработчика бэк-энда. Мне даже интересно, может ли GraphQL быть основой для будущей версии Views.

Кроме того, работа над улучшением рендеринга, такая как BigPipe, должна продолжаться для изучения возможностей и реализации лучшей системы рендеринга. В настоящее время у нас хороший прогресс по ускорению загрузки страниц с обширным или персонализированным содержанием. Также необходим дальнейший прогресс в области инструментов по управлению макетом, таких как Panels и в области размещения блоков, что сделает отвязку более простой и точнее настраиваемой.

Много работы проделано, но мы всегда хотим получить больше помощи. Работайте вместе с нами, если вам интересно работать над кодом или вы можете профинансировать такую работу. В конце концов, потенциальное влияние прогрессивной отвязки на будущее отвязанного Друпала огромно.

Заключение

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

С Друпалом 8 мы можем использовать прогрессивную отвязку для создания управляемого Друпалом скелета страницы, заполнив его наиболее тяжёлыми частями. Затем мы можем выборочно определить какие части страницы нужно отвязать, после того, как загрузка страницы будет завершена. Эта концепция прогрессивной отвязки предлагает лучшее из обоих миров. Управление макетом, безопасность и предпросмотр содержания не затрагиваются, а с компонентами страницы логика фронт-энда может работать пользуясь своей магией.

Сейчас Друпал 8 это развитая платформа для создания проектов, которые лежат между традиционными сайтами с разными типами содержания и современными интерактивными приложениями. Как всегда, несмотря на значительные успехи с Друпалом 8, у нас есть ещё много работы.

Отдельная благодарность Престону Со и Виму Лиерсу из Аквии за вклад в эту статью, и Моше Вейцману, Кевину О'Леари, Кристияну Ятесу, Дэвиду Хвангу, Майклу Пецци и Эрику Болдуину за их отзывы в процессе написания статьи.

Рубрика: