Безголовая CMS: Gatsby JS с WordPress

Общеизвестно, что WordPress охватывает примерно одну треть из 1 миллиона лучших веб-сайтов в мире с долей рынка систем управления контентом более 50%. Совсем недавно, в 2016 году, WordPress решил представить REST API, чтобы предоставить другим приложениям улучшенный доступ к контенту в базе данных WordPress. В результате разработчики получили возможность использовать WordPress в качестве безголовой CMS.

Это неизбежно подразумевало, что инженеры больше не будут ограничены использованием обычного уровня представления WordPress (внешнего интерфейса), но теперь смогут использовать любое внешнее приложение для доставки своих данных. В свете этого большая часть этого блога будет посвящена взаимодействию WordPress и Gatsby.js в отношении реализации Headless CMS.

Краткая история CMS

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

По сути, монолитная CMS — это программное приложение, которое включает в себя все необходимое для редактирования и публикации контента в Интернете. Первые из таких систем были ограничены предприятиями, такими как EpiServer, однако позже появились варианты с открытым исходным кодом, такие как WordPress, Drupal и Joomla. Остальное уже история, поскольку WordPress со временем завоевал наибольшую долю рынка.

Однако позже, во время революции смартфонов, мобильные устройства начали влиять на потребление и доставку веб-контента. Это было вызовом для традиционных монолитных CMS, предназначенных для доставки веб-контента на ноутбуки и настольные компьютеры.

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

Безголовые CMS

Как упоминалось ранее, Headless CMS не имеет уровня представления. В результате контент доставляется через API (RESTful или GraphQL) в отдельное внешнее приложение, которое затем представляет его. API делает контент доступным для любого канала и устройства с помощью различных инструментов и языков программирования с более высоким уровнем безопасности и масштабируемости.

По сути, CMS отделена от внешнего интерфейса, что, в свою очередь, позволяет разработчикам создавать богатый опыт для конечных пользователей, используя лучшие доступные технологии. «Безголовый» или «отдельный» режим в настоящее время поддерживается большинством CMS, что проложило путь для сайтов Gatsby.

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

Исполнение WordPress без головы CMS

Что касается хронологии событий, описанной выше, мы видели, как WordPress в конечном итоге реализовал Headless CMS. WordPress содержит API (интерфейс прикладного программирования), который позволяет вам расширять его с помощью плагинов (по сути, как «структуру приложений»). В частности, это достигается с помощью REST API, как мы рассмотрим позже.

Тем не менее, одной из ключевых концепций WordPress API являются хуки. По сути, хуки позволяют плагинам изменять основные функции WordPress. На практике хуки работают таким образом, что когда в WordPress происходит определенное событие (например, загрузка страницы или пост-редактирование), WordPress вызывает определенный хук для запуска функции.

В частности, крючки разделены на «Действия» и «Фильтры». Действия могут использоваться для запуска определенных функций PHP в определенных событиях, хотя функциям не нужно ничего возвращать. Хотя фильтры можно использовать для запуска функций, через которые WordPress передает данные во время определенных событий, при этом эти функции принимают данные в качестве параметра и возвращают измененную версию данных.

WordPress и REST API

Передача репрезентативного состояния (REST) ​​основана на протоколе HTTP и обеспечивает единую семантику интерфейса для создания, чтения, обновления и удаления данных (CRUD).

Как правило, выполнение REST API в WordPress позволяет разработчикам получать доступ к данным в базе данных WordPress удаленно, отправляя и получая объекты JSON (JavaScript Object Notation). Следовательно, это дает разработчикам возможность создавать, читать, обновлять и удалять данные WordPress из других приложений, которые не разработаны с помощью WordPress. Например, веб-приложения JavaScript или нативные мобильные приложения.

Однако по мере того, как мы углубляемся в понимание взаимосвязи Headless WordPress CMS с REST API и Gatsby, нам необходимо отметить несколько фундаментальных концепций WordPress API:

• Маршруты и конечные точки. Маршруты — это пути, к которым вы можете получить доступ через вызов HTTP, а конечная точка — это метод HTTP (например, получение, отправка, размещение или удаление), сопоставленный с этим маршрутом.
• Запрос: Когда вы инициируете HTTP-запрос к зарегистрированному маршруту REST, WordPress автоматически создает объект запроса. Данные, указанные в запросе, будут определять, какой ответ вы получите.
• Response: объект Response — это данные, которые вы получаете обратно, когда делаете запрос. Он может состоять из запрошенных данных или сообщений об ошибках.
• Схема: Схема относится к структуре данных в конечной точке. Каждая конечная точка может иметь слегка или значительно отличающуюся структуру данных, которые она может возвращать. Соответственно, схема будет определять все возможные свойства, которые конечная точка может вернуть, и все возможные параметры, которые она может получить.
• Классы контроллеров. Классы контроллеров позволяют разработчикам управлять конечными точками и маршрутами и регистрировать их, а также позволяют им обрабатывать запросы, использовать схему и генерировать ответы.

React «Структура»

Теперь, когда мы углубляемся в суть отношений Gatsby.js и WordPress, для большего контекста мы должны расшифровать этот технологический ландшафт из более исторических основ. React играет ключевую роль в этой истории, поскольку это самая быстрорастущая библиотека/фреймворк JavaScript для внешнего интерфейса. Прославившиеся благодаря Facebook (его основным разработчикам), другие крупные веб-сайты используют React для своих интерфейсов, например: Airbnb, Netflix, Dropbox, BBC, PayPal, Reddit, Salesforce, Squarespace и Tesla.

Следовательно, поскольку React на практике является библиотекой (поскольку в ней все еще отсутствуют заметные функции полноценного фреймворка), это означает, что на его основе могут быть разработаны другие «фреймворки». В результате одним из них является Gatsby.js.

Представляем Гэтсби

Согласно его родительскому веб-сайту, Gatsby.js — это бесплатная среда JavaScript с открытым исходным кодом, основанная на React, которая помогает разработчикам создавать быстрые веб-сайты и приложения. В принципе, Gatsby.js генерирует статические HTML-страницы из приложений для начальной загрузки, а затем работает как одностраничное приложение React (SPA).

Gatsby.js Свойства

В этих условиях Gatsby использует принципы Progressive Web App (PWA), чтобы сначала получить только необходимые элементы, а затем загрузить остальную часть приложения в фоновом режиме. Кроме того, чтобы обеспечить загрузку только необходимых данных, Gatsby использует язык запросов GraphQL (также от Facebook) для загрузки данных из источника. Он также поддерживает исключительную оптимизацию изображения.

Объединение всех этих возможностей дает разработчикам необходимые инструменты для создания максимально быстрых веб-сайтов и веб-приложений, поскольку загружаются только важные HTML, CSS, данные и JavaScript. Итак, как только страница загружается, Gatsby предварительно выбирает ресурсы для связанных страниц, и поэтому навигация по сайту кажется довольно быстрой.

Кроме того, поскольку страницы генерируются при компиляции перед размещением в Интернете, вам больше не нужны мощные серверы PHP, и вы можете обслуживать статические файлы (HTML, JS и CSS, непосредственно из хранилища). Кроме того, поскольку Gatsby работает на React, вы сможете красиво структурировать все с помощью компонентов. Этот модульный аспект позволяет разработчикам легко повторно использовать компоненты.

Другие важные стандартные функции Gatsby включают в себя:

• Генератор статических сайтов
• Офлайн-доступ
• Предварительная загрузка связанных страниц
• Кэширование страниц
• Нет извлечения постороннего кода
• Экспортировать как код
• Горячая перезагрузка контента
• Код горячей перезагрузки
• Компонентизация
• Односторонняя привязка данных
• Декларативные запросы данных API (GraphQL)
• Декларативный пользовательский интерфейс
• Прогрессивная загрузка изображений
• Адаптивная загрузка изображений
• Встраивание критического CSS
• Самостоятельный хостинг шрифтов
• Бессерверный
• Воронки активов
• CSS-расширения (SaSS)
• Расширенный синтаксис JavaScript
• Экосистема компонента React

Плагины Гэтсби

По сути, плагины Gatsby — это, по сути, пакеты Node.js, использующие API Gatsby. Эти плагины могут добавлять источники данных, преобразовывать данные в другие форматы и добавлять сторонние сервисы. Хотя Gatsby.org поддерживает библиотеку плагинов, которая включает в себя множество уже созданных плагинов, созданных либо основной командой Gatsby, либо сторонними организациями. В идеале, чтобы установить плагин для проекта Gatsby, разработчики используют диспетчер пакетов узла (NPM) на своем терминале UNIX и запускают команду npm install.

Как GraphQL приходит относится к Гэтсби.

GraphQL вращается вокруг идеи, что вы можете описать API именно те данные, которые вам нужны, и вы получите именно это. В результате он более эффективен, чем REST. Для этого Gatsby использует Webpack и GraphQL. Что еще более важно, с GraphQL в качестве языка запросов все определяется на стороне клиента, выполняющего запрос, при этом клиент не обращает внимания на работу приложения.

Эта уникальная реализация позволяет разработчикам подключать любой источник данных к Gatsby. Например, сообщения в блогах могут поступать из файлов Markdown, таблиц Google или даже с другого веб-сайта WordPress. Таким образом, обеспечивается повышенная гибкость при доставке контента.

Механизм Gatsby-WordPress (исходные плагины)

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

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

Плагин «Gatsby-source-WordPress» создается и поддерживается основной командой Gatsby и извлекает данные либо с собственных сайтов WordPress, либо с WordPress.com. Это также влечет за собой аутентификацию OAuth для Word-Press.com API, а также позволяет разработчикам запрашивать адаптивные изображения.

По сути, этот плагин поддерживает все объекты в WordPress REST API, такие как сообщения, страницы, теги, категории, мультимедиа, типы, пользователи, статусы, таксономии, метаданные сайта и пользовательские типы сообщений. Кроме того, также поддерживаются объекты расширенных настраиваемых полей (ACF) и языковая информация Polylang и WPML в дополнение к другим метаданным сообщений, зарегистрированным в REST API.

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

На практике инструмент «Gatsby-source-WordPress» предоставляет ярлык для всех сообщений и других объектов. Таким образом, все, что нужно сделать инженеру, — это создать страницу, вызвав функцию createPage. Это выполняется в файле Gatsby-node.js, обычно сначала выполняется запрос к источнику данных, а затем вызывается createPage для каждого найденного узла, а затем устанавливается файл шаблона, который будет использоваться в качестве компонента.

CI/CD и автоматизация выпуска приложений.

При внедрении безголовой WordPress CMS с Gatsby очень важно, как выполняется развертывание. Как правило, такие выполнения требуют автоматизации развертывания приложения с использованием автоматизации выпуска приложений (ARA).

Как правило, ARA влечет за собой основные функции:

• Развертывание данных, кода приложения и артефактов.
• Развертывание определенных конфигураций для каждой среды
• Процесс проектирования рабочего процесса для автоматизации задач и этапов развертывания.
• Наконец, моделирование среды и/или подготовка двоичных файлов.

Поскольку Gatsby создает статические сайты, необходимо настроить конвейер ARA, чтобы при обновлении контента в WordPress он мог соответственно обновляться на сайте Gatsby. Обычно непрерывное развертывание запускается только при изменении кода, однако в данном случае желательно запускать его при изменении данных. Итак, для этого мы рекомендуем использовать Netlify поскольку он обладает потрясающими встроенными возможностями непрерывного развертывания и удобен в настройке.

Запросы из WordPress с использованием GraphQL и gatsby-source-WordPress

В качестве иллюстрации gatsby-source-WordPress работает таким образом, что сначала он получает все на вашей конечной точке с помощью REST. Затем он сгенерирует внутренний API GraphQl на основе этих данных. Впоследствии он будет обрабатывать ваши запросы и собирать данные из этого внутреннего API GraphQL. Таким образом, ваша сборка заканчивается только теми данными, которые вы запросили, и ничем другим.

Преимущества разработки Headless WordPress с Gatsby.js

Поскольку мы коснулись разработки Headless WordPress с Гэтсби, теперь мы можем рассказать о плюсах такого технического подхода. Это должно существенно повлиять на ваше решение о том, усыновить Гэтсби или нет!

• Первым преимуществом является возможность иметь статический предварительно обработанный сайт. Это наиболее эффективный способ отображения веб-страницы, а поскольку Gatsby использует GraphQL для выполнения минимально необходимого объема данных, это обеспечивает дополнительную эффективность в течение времени после первоначальной загрузки.
• Улучшенная SEO-видимость: статические страницы легко читаются поисковыми системами, поскольку все предварительно отображается и индексируется. Это положительно, в отличие от других безголовых механизмов, где рендеринг страниц с помощью JavaScript является проблемой, связанной с поисковой оптимизацией (SEO).
• Относительно быстрая скорость разработки: по сравнению с другими безголовыми подходами Gatsby имеет один унифицированный, простой для понимания способ получения данных независимо от источника. Это значительно упрощает разработку, поскольку вы можете сосредоточиться на своем реальном сайте и позволить Гэтсби выполнять большую часть тяжелой работы.
• Более дешевый хостинг: вы можете разместить свое приложение Gatsby где угодно, поскольку оно просто обслуживает статические файлы, что сокращает расходы на хостинг. Кроме того, поскольку WordPress вызывается только во время процесса сборки, а не во время пользовательского сеанса, его также можно разместить на доступном хостинге.
• Повышенная безопасность. Вообще говоря, генераторы статических сайтов чрезвычайно безопасны, поскольку нет прямого подключения к базе данных, зависимостям, пользовательским данным или другой конфиденциальной информации.
• Без плагинов: с точки зрения не разработчика, WordPress довольно прост в эксплуатации из-за доступных плагинов. Однако это ограничивает реализацию пользовательских функций. К сожалению, слишком много плагинов также могут замедлить работу сайта, так как он становится тяжелым и трудным для отображения. Казнь Гэтсби, по сути, обходит все эти узкие места.

Дополнительные аспекты, которые могут побудить вас рассмотреть Gatsby с WordPress:

• Простая в управлении панель администратора WordPress.
• Готовая к использованию система входа пользователей и авторизации.
• С редактором Gatsby и Gutenberg вы можете создать конструктор сайтов Gatsby с помощью перетаскивания.

Недостатки разработки Headless WordPress с помощью Gatsby.js

• Ограничения обновления. Когда контент меняется с нуля, он устанавливает ограничения на частоту обновления вашего сайта. Кроме того, запуск сборки Gatsby может занять до 10 минут, если ваш сайт содержит много данных, что может быть проблемой для сайтов, которые часто обновляются.
• Регулярные обновления: Кроме того, поскольку Gatsby является генератором статических сайтов, его нельзя просто «редактировать», так как даже небольшое изменение текста потребует нового развертывания. Таким образом, если у вас есть страница, которая требует много динамических ежедневных изменений контента, это может занять много времени и суеты.
• Задержки: обычно вам приходится ждать несколько минут, чтобы увидеть изменения в вашем контенте по мере их публикации.
• Отсутствие предварительного просмотра: в отличие от традиционных приложений WordPress, у вас нет предварительного просмотра в Gatsby. К сожалению, это была самая большая проблема, которую создатели контента обнаружили с Гэтсби. Вам нужно будет скомпилировать все, возможно, с конвейерами Gitlab CI/CD, которые компилируют веб-сайт и размещают все в Интернете.
• Крутая кривая обучения: как правило, если вы хотите работать с Gatsby и WordPress одновременно, вам необходимо быть относительно знакомым с языками PHP и JavaScript. Поскольку Гэтсби объединяет React и GraphQL, для многих это может быть крутой кривой обучения.

Последние мысли.

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

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

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