Вы здесь

Встраивать ли в Друпал клиентский фрейм-ворк?

Со времени получения пользователями опыта работы не только со статичными страницами, но и со страницами приложений, ожидания пользователей от сайта растут. Лента новостей Facebook, страница полученной почты в Gmail, поток сообщений в Twitter — всё это примеры того, какие возможности пользователи теперь воспринимают как должное и ждут от сайта.

Многие страницы управления сайтом и страницы доступные пользователям, могли бы получить преимущества от такого бесшовного, мгновенного взаимодействия. Интерфейс Друпала для моделирования содержания (Field API), управления макетом (Panels) и блоками выиграют от обновления страниц, мгновенного предпросмотра и интерфейса предпросмотра. Эти черты могут также улучшить впечатления пользователя от сайта; возможности по комментированию содержания в Друпале тоже бы выиграли, если их сделать похожими на комментирование сделанное в Facebook.

Как руководитель проекта Друпал, я спрашиваю себя: как наше сообщество может почувствовать возможности и начать строить подобные интерфейсы?

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

Вот что я сейчас думаю: в краткосрочной перспективе Друпал должен работать над новым интерфейсом взаимодействия при прогрессивной отвязке как для управляющих, так и для посетителей сайта. В то же время мы должны идти к тому, чтобы Друпал позволял использовать и полностью отвязанный интерфейс для пользователя и управляющего. На мой взгляд, лучший способ добиться этого, это формально стандартизировать полнофункциональный MV* фрейм-ворк (например Angular, Ember, Backbone, Knockout) или библиотеку на основе компонентов (React, Vue, Riot). В этой статье я хочу начать обсуждение и подробно рассказать о своей позиции.

Должны ли мы отвязать Друпал сам по себе?

Should we decouple Drupal with a client-side framework?

Фрейм-ворк может взять на себя как небольшую ответственность (Backbone), так и большую, включая процесс рендеринга.

Вопрос на который нам нужно ответить: выиграем ли мы от отвязки Друпала? В этом контексте, отвязанный Друпал связан с разделением на бэк-энд на Друпале и одним или несколькими фронт-эндами. В отвязанной архитектуре бэк-энд сделан на серверном языке, таком как PHP, а фронт-энд сделан на клиентском языке, таком как JavaScript, и данные передаются между ними. Отвязывание системы управления содержанием даёт фронт-энд-разработчикам больший контроль за приложениями или макетом генерируемым сайтом и взаимодействием с ним пользователей, а использование фронт-энда даём им лучшие инструменты по созданию приложений удобных пользователю.

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

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

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

Третий вариант это то, что я называю прогрессивной отвязкой, в котором Друпал рендерит шаблон на стороне сервера для обеспечения начального состояния приложения, а JavaScript затем манипулирует этим состоянием. Это означает, что мы берём лучшее из двух миров: ненавязчивый JavaScript и все наши преимущества с быстродействием в Друпале 8 — малое время первой прорисовки (когда пользователь видит появление страницы) с помощью BigPipe, а также интерактивный предпросмотр и статичный запасной вариант до первого взаимодействия (когда пользователь может выполнить какое-либо действие). Кроме того, пока дополнительный JavaScript занимается прорисовкой, прогрессивная отвязка уменьшает количество изменений нужных для внесения в стек опираясь на возможности темизации.

Подход Пользователь Разработчик Сложность
Традиционное связывание – Обновления страницы
– Отсутствие мгновенной обратной связи
– Рабочий процесс со швами
– Сохранённый слой темизации
– Модули в основном на PHP
– Подходящий для клиента код
– PHP и минимум JavaScript
– Без изменений на стороне сервера
– Без изменений на стороне клиента
Прогрессивная отвязка – Нет перезагрузок страницы
– Немедленная обратная связь
– Бесшовный рабочий процесс
– Сохранённый слой темизации
– Модули на PHP и JavaScript
– Унифицированный клиентский код
– PHP и JavaScript
– Некоторые изменения на стороне сервера
– Некоторые изменения на стороне клиента
Полная отвязка – Нет перезагрузок страницы
– Немедленная обратная связь
– Бесшовный рабочий процесс
– Слой темизации заменён
– Модули переписываются на JavaScript
– Унифицированный клиентский код
– В основном JavaScript
– Большие изменения на стороне сервера
– Большие изменения на стороне клиента

Как Друпал должен отвязать свой интерфейс?

Should we decouple Drupal with a client-side framework?

При полной отвязке приложение строится с помощью клиентского фрейм-ворка, который управляет всем интерфейсом. При прогрессивной развязке начальное состояние реализуется уровнем темизации, после чего JavaScript манипулирует уже им.

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

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

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

Тем не менее, нам нужно предоставить людям возможность создания полностью отвязанных сайтов и приложений. В зависимости от случая использования, Друпал 8 хорошо подходит для отвязанных приложений, но нам нужно улучшить и расширить REST API, такие дополнительные модули как Services и внедрить новые возможности подобные GraphQL (демонстрационное видео), чтобы больше возможностей могли быть отвязаны. Благодаря чему фронт-энд разработчики могут использовать фрейм-ворк по своему выбору, будь то Angular, Ember, React или какой-то другой, чтобы создать полностью отвязанное приложение управления.

Должен ли Друпал быть стандартизирован с одним фрейм-ворком?

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

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

Например Backbone.js, со своей базовой библиотекой Underscore.js, сейчас поддерживает взаимодействие с панелью инструментов и встроенным редактированием в Друпале 8. Хотя Друпал может расширить использование Backbone в ядре и предложить фронт-энд-разработчикам работать с ним, это означает погружение на долгое время в фрейм-ворк, который выглядит уже достаточно устаревшим среди своих товарищей.

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

На основе какого фрейм-ворка нужно стандартизировать Друпал?

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

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

На второй вопрос, как мы стандартизирумся, я могу помочь ответить. С одной стороны Друпал может включить клиентский фрейм-ворк в своё ядро и распространяться с ним. Это будет выглядеть как заимствование jQuery и Backbone.js. С другой стороны, мы можем рекомендовать определённый фрейм-ворк, но не распространять его с Друпалом. Наконец где-то между этими двумя вариантами, Друпал может распространяться со стандартным фрейм-ворком в ядре, но сделать его замену лёгкой, хотя вероятность этого довольна мала. Это будет похоже на распространение с Друпалом движка шаблонов, который в случае необходимости может быть заменён другим (как в случае с PHPTemplate). Я думаю, что мы получим лучший результат, если Друпал будет распространяться с определённым фрейм-ворком, как это было с принятием jQuery в Друпал 5.

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

Заключение

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

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

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

Отдельная благодарность Престону Со и Виму Лиерсу за вклад в эту статью и Моше Вейцману с Габором Хойцы за отзывы во время её написания.