1. Главная

Drupal + Gatsby.js

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

Max-Z 15 декабря 2018 в 14:16

Решил ознакомиться с темой статических сайтов и сделать небольшой decoupled (он же headless) Drupal сайт с фронт-ендом, полностью написанным на React — https://z-portfolio.tk.

Изначально для реализации задуманного я выбрал Next.js, но в процессе работы неприятно удивил целый ряд недостатков и костылей. Пришлось отказаться от Next в пользу свежевышедшего Gatsby.js ver 2.

Первая приятная неожиданность — Gatsby имеет специальный плагин для Drupal, позволяющий легко и непринуждённо подгружать контент через новомодный GraphQL, используя визуальный интерфейс. Никакого шаманизма, обнаженки и ритуальных танцев, всё работает "из коробки".

Кроме удобства разработки, порадовал и процесс деплоя. В качестве хостинга был выбран Netlify. В нём нужно было просто привязать мой репозиторий проекта на Gitlab и вуаля — при каждом коммите он автоматически деплоит на продакшн (опция на любителя, но для моего случая то, что надо).

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

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

Всем удачи!

Автор

Max-Z
  • Drupal8
    • Разработчикам

    Комментарии

    Аватар пользователя bumble bumble 15 декабря 2018 в 19:05

    Спасибо за материал!

    Небольшой FYI:
    - Статические сайты - это совсем про другое, это готовый ХТМЛ, без динамики (пред / пост обработок)
    - Headless и Decoupled - тоже не одно и то же Wink Хоть и похожи. Тут можно читнуть.

    Ну, и круто было бы о реализации упомянуть. Что использовалось, как и главное - зачем ))

    Аватар пользователя Max-Z Max-Z 15 декабря 2018 в 19:37

    Если честно, то статические сайты - это именно про то, а не другое. Введите в поиск Static site generators, и Gatsby будет среди первых ответов. Выражается это в частности в том, что каждый раз, когда я обновляю контент в Drupal, мне нужно заново сделать gatsby build и задеплоить новую версию.
    По поводу decoupled в основном я делаю progressive decouple, где ее компоненты React внедряются как отдельные элементы на страницы, генерируемые Drupal, но в данном случае имеем полный decouple, где друпал выступает просто как сервер для генерации контента.
    Я чуть позднее распишу детали.

    Аватар пользователя bumble bumble 15 декабря 2018 в 19:44

    Сорри, я не особо вникал в тонкости работы Gatsby, и решил что это очередной фреймворк для фронта, а из выдержек:

    Drupal сайт с фронт-ендом, полностью написанным на React.

    и

    позволяющий легко и непринуждённо подгружать контент через новомодный GraphQL

    сделал вывод о классическом интерфейсе работы с API, которая исключает статичность.

    Аватар пользователя Max-Z Max-Z 16 декабря 2018 в 12:21

    gun_dose wrote:

    А что в нексте не так?


    Речь идёт не о Next.js в целом, а о применении её в моей конкретной задаче. К сожалению, не запомнил всех моментов, которые меня огорчили (сайт этот делал в свободное время понемногу, и с Next я начал ещё в августе), но кое-что всё же запомнилось. Например, для поддержки самой популярной на сегодня UI-библиотеки для React – Antd потребовались немыслимые костыли, в то время, как в Gatsby достаточно установить плагин .

    А поддержки Antd, кстати, нет и по сей день.
    Конечно, это не критическая проблема, но неплохо демонстрирует разницу подходов двух обсуждаемых фреймворков к использованию популярных инструментов для разработки.
    Вообще, мне показалась близкой и логичной модульная архитектура Gatsby. В активной разработке находятся плагины на все случаи жизни. Вот плагин для Drupal. Всё, что требуется для интеграции Drupal, это установить модуль JSONAPI (последняя версия RC3 глючная, ахтунг!) и в конфиг-файле Gatsby указать URL вашего Drupal-сайта.

    При запуске Gatsby автоматически создаёт Schema со структурой вашего контента.
    Далее через интерфейс GraphiQL запрашиваем нужные поля (можно изучить сгенерированную Schema через этот же интерфейс, чтобы понять что где находится, а можно написать в левом окне query {} и нажимая shift+space выбирать доступные поля из предложенного dropdown-меню.

    Кстати, такую же удобную интеграцию GraphQL имеет и взлетающий на гребне популярности React-apollo.

    Аватар пользователя Max-Z Max-Z 16 декабря 2018 в 13:31

    bumble wrote:

    Сорри, я не особо вникал в тонкости работы Gatsby, и решил что это очередной фреймворк для фронта...

    Не проблема, для меня самого это новая тема, в которой я хочу лучше разобраться. Клиенты уже начинают просить “сделай мне так же”, но я до конца не понимаю, где заканчиваются возможности статических сайтов.
    Вот немного теории по теме.
    bumble wrote:

    Ну, и круто было бы о реализации упомянуть. Что использовалось, как и главное - зачем ))

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

    Для базовой разметки использовалась UI-библиотека Antd.

    CSS пишется для каждого компонента отдельно без всяких классов благодаря удобному Styled components. Некоторое время я не мог понять и простить этого подхода взамен полюбившегося SASS/LESS, но вот эта презентация от создателя таки донесла до меня идею.

    Анимация сделана с помощью свежего компонента React-spring. Он позволяет представить любое свойство CSS в виде “пружины” и детально прописать уровень её “жесткости” и другие параметры. Засечки, отслеживающие положение экрана, сделаны благодаря React Waypoint.

    Эффект печатной машинки в разделе My Tech на главной – это React Typist.

    Вот эта карусель сделана в React Coverflow.

    Галерея использует три компонента React-Images, React Photo Gallery и React Measure для адаптивности.

    Как видите, React (в отличие от Drupal) имеет богатый front-end инструментарий. Можно найти готовые решения на любой вкус, обходясь минимумом ручной работы. Особо приятно, что в виду нарастающей популярности самого React (на днях в npm trends он перевалил за 4 миллиона установок в день!), этот инструментарий продолжает активно расширяться.

    Gatsby также имеет собственный набор плагинов для SEO.

    Весь проект разбит на множество отдельных компонентов, минимум каши и спагетти-кода.

    Хотя, обилие анимации всё же создаёт небольшое нагромождение кода:)

    Аватар пользователя gun_dose gun_dose 16 декабря 2018 в 18:45

    Можно поподробнее, что нужно сделать после публикации нового контента?

    И второй вопрос: так ли хороши styled components? Не увеличивают ли они количество кода за счёт отсутствия каскадностп? И куда в итоге попадают скомпилированные стили?

    Аватар пользователя Max-Z Max-Z 16 декабря 2018 в 20:15

    Большим отличием от обычного приложения React, интегрированного с Drupal, является момент, когда осуществляется fetch. В обычном приложении, как Вы знаете, это происходит при обращении к компоненту или в любой другой, установленный разработчиком момент (нажатие кнопки и т.д.)
    В Gatsby это происходит в момент сборки (не важно dev или build)

    Т.е. после обновления контента в Drupal я запускаю две команды gatsby build, затем git commit. Поскольку в Netify у меня выбран continuous deployment, и он привязан к моему Gitlab-репозиторию, этого достаточно для того, чтобы продакшн-версия обновилась в течение минуты.
    Styled Components мне понравился тем, что в отличие от остальных методов CSS-in-JS он не вводит никаких изменений в синтаксис самого CSS. Просто берётся любой элемент HTML, например, <div> и ему присваивается любое разумное название, например, <SectionWrapper> если он служит обёрткой для секции или просто <StyledWrapper> Далее прямо в этом же компоненте одноимённой переменной в обратных ковычках (template strings) присваиваются нужные свойства CSS.

    Для повторяющихся значений существует theming
    В отдельном файле создаём переменные, затем используем их где угодно с помощью вот такого синтаксиса:
    color: ${(props) => props.theme.colorPrimary};
    С media queries тоже всё проще некуда:

    При сборке всё это конвертируется в обыкновенный CSS с длинными названиями классов (пример - MyTechComponent__StyledH1-sc-13xb279-1), которые гарантировано не пересекутся с каким-нибудь другим UI-Framework'ом или ранее созданным классом.

    Аватар пользователя gun_dose gun_dose 17 декабря 2018 в 10:07

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

    Про невозможность интеграции антд с некстом не верю.

    Аватар пользователя gun_dose gun_dose 17 декабря 2018 в 11:34

    Там issue не открытый, а закрытый)) Ну да ладно, не в этом суть. С некстом вообще абсолютно всё интегрируется через боль)))

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

    Аватар пользователя Max-Z Max-Z 17 декабря 2018 в 12:02

    gun_dose wrote:
    Для визиток, корпоративных сайтов и простых интернет-магазинов это всё будет только лишним усложнением.

    Согласен, хотя работать в связке Drupal+Gatsby для меня было одно удовольствие (учитывая изначальную простоту проекта).
    Случаи, когда decouple действительно полезен довольно ограничены, но они есть. Например, сейчас работаю над большим проектом, в котором Drupal выступает единственным источником контента для целого ряда приложений, в т.ч. использующих React.
    Возможно, в данный момент мы находимся в переходном периоде, когда подобные headless связки не совсем оправданы, но если Drupal будет развиваться, как заявлено, нас ждёт весьма интересное время:)

    Аватар пользователя gun_dose gun_dose 17 декабря 2018 в 12:43
    1

    Max-Z wrote:

    работать в связке Drupal+Gatsby для меня было одно удовольствие

    Да это очень интересно. Но потом как посмотришь, сколько времени ушло на проект, то сразу становится всё понятно)))

    Кстати, ещё один момент по decoupled: все эти JSON:API и GraphQL по началу кажутся очень крутыми, но потом со временем надоедают, т.к. на фронте постоянно приходится писать сложные запросы и парсить не менее сложные ответы на них. Когда добираешься до subrequests, то начинаешь в панике оглядываться на проекты других людей, смотришь во вкладку Network в девтулзах и постоянно задаёшься вопросом, почему у них красивый json, а у тебя непонятная белиберда с кучей вложенностей и инклюдами, идущими всегда не по месту. И в такой момент начинаешь понимать, что для многих вещей проще и удобнее собрать REST-вьюху, а где-то кастомный рест-эндпоинт сможет убрать головную боль и повысить производительность.

    Как бы то ни было, от JSON:API я полностью отказываться не собираюсь, но местами уже стараюсь избегать.

    Аватар пользователя Max-Z Max-Z 17 декабря 2018 в 12:54

    Мне тоже не нравятся эти километровые линки в JSONAPI с фильтрами и инклюдами, которые надо собирать вручную, ковыряясь в документации. В GraphQL это реализовано по-человечески - выбирай из списка полей и копируй готовый сниппет.
    К счастью, судя по тенденциям, GraphQL рано или поздно станет стандартом.