Розділений decoupled, headless Drupal

Зараз вимоги бізнесу до реалізації веб-додатків значно змінилися. Найчастіше створення простого сайту або веб-додатка з фіксованим джерелом споживання даних уже недостатньо. Кількість каналів, яким потрібні дані додатки, стрімко розширюється — від мобільних телефонів, годинників, комп'ютерів, інших різних пристроїв до систем, призначених тільки для внутрішнього використання бізнесом, а також чатів і соціальних мереж. Все частіше замовнику потрібен не просто сайт, а повноцінний додаток, який буде працювати на декількох видах пристроїв, буде доступним усюди, реалізує складну логіку обробки введених користувачем даних, матиме широкі можливості для кастомізації і підтримуватиме максимальну кількість сучасних технологій. Розуміючи це, розробники Drupal при створенні 8 версії почали закладати в систему принцип API-first для реалізації розділеного Drupal. Вихід нової дев'ятої версії Drupal у 2020 році тільки закріпив архітектуру, орієнтовану на API, а також включив в ядро модуль JSON — API, який дозволяє створювати надійні незалежні і автономні програми. Дана стаття буде першою у циклі статей про розділений Drupal.

Так що ж означає decouple, або headless Drupal? Термін decouple в перекладі з англійської означає "розділений", тобто те, що Drupal розділений, і від нього відокремлена та частина, яка відповідає за формування і висновок інформації користувачеві. Термін headless буквально означає "без обличчя". Обличчям ("веб-мордою") заведено називати веб-інтерфейс — те, що бачить користувач і за допомогою чого він взаємодіє з додатком. Можна сказати що розділений Drupal — це Drupal, з якого прибрана частина, що відповідає за формування і висновок призначеного для користувача інтерфейсу, це весь шар тем Drupal (теми сайту, хукі препроцеса, функції рендеринга і інші складові ThemeAPI).При цьому підході 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 на стороні фронтенда.