Как включить GraphQL в WordPress: обзор WPGraphQL и GraphQL API for WordPress

Headless WordPress в последнее время становится все более модным. Всего за несколько недель мы увидели массу новых разработок и решений, связанных с этим подходом. Одна из причин такой активности – выход WPGraphQL 1.0, сервера GraphQL для WordPress.

WPGraphQL предлагает GraphQL API: способ извлечения данных из WordPress и их публикации на сайте. Этот метод позволяет нам отделить процессы управления контентом (что делается через WordPress) от процессов сборки сайта (для этого мы можем использовать библиотеки любого интересующего нас фреймворка, включая React, Vue.js, Gatsby, Next.js).

До недавнего времени WPGraphQL был единственным GraphQL-сервером для WordPress. Однако затем появился еще и GraphQL API for WordPress.

Эти два плагина служат одной цели: привязке GraphQL API к WordPress-сайту. Вы можете спросить: зачем еще один плагин, если уже есть WPGraphQL? Эти два плагина делают одно и то же? Или они для разных ситуаций?

Сразу замечу следующее: WPGraphQL справляется со всеми задачами прекрасно. Новый плагин был создан не в результате каких-то проблем с WPGraphQL.

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

В этой статье я покажу, в какой ситуации лучшим вариантом будет WPGraphQL, а в какой — GraphQL API for WordPress.

Используем WPGraphQL, если работаем с Gatsby

Если вы разрабатываете сайт с помощью Gatsby, то в таком случае у вас один вариант: WPGraphQL. Создатель WPGraphQL, Джейсон Бал, до недавнего времени сам работал в Gatsby. По этой причине WPGraphQL прекрасно работает в связке с source-плагином для Gatsby.

Gatsby получает все данные с WordPress-сайта, и с этого момента вся логика приложения ложится на плечи Gatsby, а не WP. Следовательно, дополнения к WPGraphQL (такие как директивы @stream или @defer) уже не будут иметь значения.

WPGraphQL уже настолько хорош, насколько это требуется Gatsby.

Используем WPGraphQL, если работаем с одним из новых Headless фреймворков

Как уже говорилось ранее, в последнее время в пространстве Headless WordPress произошел всплеск активности – появились новые фреймворки, а также стартовые проекты, основанные на Next.js:

• Next.js WordPress Starter от Colby Fayock
• Next.js WordPress Starter от WebDevStudios
• Headless WordPress Framework от WP Engine

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

Используем любой плагин, если работаем с Frontity

Frontity – это React-фреймворк для WordPress. Он позволяет создавать React-приложения с бэкэндом на WordPress. Даже создание записей блога с помощью WordPress-редактора поддерживается «из коробки».

Frontity по умолчанию основан на REST, однако для него можно использовать GraphQL путем подключения source-плагина.

В данном контексте Frontity функционирует очень грамотно: source-плагин является интерфейсом для взаимодействия с поставщиком данных. Сейчас единственный доступный source-плагин – это плагин для WordPress REST API. Однако любой разработчик может сделать source-плагин для WPGraphQL или GraphQL API for WordPress (именно такой подход в идеале должен быть у всех Next.js-фреймворков).

Заключение: для работы с Frontity подходят оба плагина, но нужно будет подключать их самостоятельно.

Используем WPGraphQL, если создаем статичный сайт

В первых двух разделах вывод был один и тот же: используйте WPGraphQL. Однако моя реакция в этих разделах была различной. Если в случае с Gatsby я ни о чем не сожалел, то в случае с Next.js я ощущал нехватку возможностей.

Почему так?

Разница в том, что Gatsby – это генератор статичных сайтов, а Next.js может генерировать как статичные, так и динамические (live) сайты.

Я упоминал, что WPGraphQL уже достаточно хорош для Gatsby. Это утверждение можно расширить: WPGraphQL уже достаточно хорош для любого генератора статичных сайтов.

Даже если GraphQL API for WordPress и предложит дополнительные возможности, все это вряд ли как-то повлияет на генератор статичных сайтов.

Следовательно, поскольку WPGraphQL уже достаточно хорош и полностью поддерживает схемы GraphQL (что пока еще разрабатывается в GraphQL API for WordPress), он будет лучшим вариантом сейчас и в обозримом будущем.

Используем GraphQL API, если нам нужно использовать GraphQL на live-сайте (не статичном)

Описанная выше ситуация меняется, если мы хотим, чтобы GraphQL получал данные с live-сайта – к примеру, при запуске мобильного приложения или при отображении данных в реальном времени на сайте (для вывода аналитики и т.д.). Также этот сценарий использования будет актуален при объединении статичного и live-подхода на одном сайте.

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

Есть два подхода: статичный и live (или динамический). Если мы выберем статичный подход, то тогда комментарии будут обрабатываться вместе с остальной частью сайта. Затем всякий раз, когда появится новый комментарий, нам нужно будет дергать веб-хук для перестройки и повторного развертывания сайта.

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

В такой ситуации имеет смысл выводить веб-сайт статично без комментариев, а затем извлекать комментарии с live-сайта и обрабатывать их динамически.

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

Вернемся к обсуждению GraphQL: почему я рекомендую GraphQL API for WordPress при работе с данными в реальном времени? Я делаю это потому, что сервер GraphQL может напрямую влиять на приложение — в основном с точки зрения скорости и безопасности.

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

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

В этом отношении GraphQL API for WordPress имеет несколько преимуществ перед WPGraphQL.

WPGraphQL предлагает некоторые меры безопасности, такие как отключение Schema Introspection по умолчанию. Однако GraphQL API for WordPress идет еще дальше, отключая единственную конечную точку по умолчанию (и в нем есть другие меры безопасности тоже). GraphQL API for WordPress изначально предлагает постоянные запросы.

Что касается скорости, постоянные запросы позволяют сделать API быстрее, поскольку ответ кэшируется через HTTP-кэширование на нескольких уровнях, включая клиента, CDN и сервер.

По этим причинам GraphQL API for WordPress лучше подходит для работы с live-сайтами.

Используем GraphQL API, если предлагаем разные данные для отдельных групп пользователей или приложений

WordPress – это универсальная система управления контентом. В зависимости от контекста нам может потребоваться GraphQL API для предоставления разных данных:

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

Чтобы передавать разные данные, нам нужно предоставить разные версии схемы GraphQL.

WPGraphQL позволяет изменять схему (к примеру, мы можем удалить зарегистрированное поле). Однако процесс непростой: изменения схемы должны быть закодированы, и нелегко понять, что к чему обращается (к примеру, все схемы должны быть доступны через единую конечную точку /graphql).

Напротив, GraphQL API for WordPress изначально поддерживает этот вариант: он предлагает настраиваемые конечные точки, которые могут передавать разные данные для разных контекстов, к примеру:

• /graphql/mobile-app и /graphql/website,
• /graphql/pro-users и /graphql/regular-users.

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

Эти возможности напрямую интегрируются с редактором WordPress (к примеру, с Gutenberg). Создание разных схем делается визуально, аналогично созданию записей в блоге. То есть создавать произвольные GraphQL-схемы может любой пользователь, не только профессиональный разработчик.

GraphQL API for WordPress является удачным вариантом для данного случая использования.

Используем GraphQL API, если взаимодействуем со сторонними сервисами

GraphQL – это не просто API для получения и публикации данных. Что не менее важно (хотя этим часто пренебрегают), он также может обрабатывать и менять данные. К примеру, в процессе передачи их некоторому стороннему сервису (отправка текста стороннему API для исправления грамматических ошибок, загрузка изображений в CDN).

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

Я не знаю, насколько хорошо WPGraphQL взаимодействует с внешними сервисами, поскольку в его документации это не упоминается, а в кодовой базе нет примеров каких-либо директив.

Напротив, GraphQL API for WordPress имеет устойчивую поддержку директив. Каждая директива в запросе выполняется только один раз в целом (в отличие от одного раза на каждое поле или на каждый объект). Эта возможность обеспечивает эффективную связь со сторонними API, выполняя интеграцию GraphQL API с разными сервисами.

К примеру, следующий запрос демонстрирует вызов Google Translate API через директиву @translate, чтобы перевести заголовки и цитаты разных записей с английского на испанский. Все поля для всех записей переводятся вместе за один вызов.

GraphQL API for WordPress является хорошим вариантом для данного сценария использования.

Примечание: движок, на котором основан GraphQL API for WordPress — GraphQL by PoP, — был специально разработан для обеспечения расширенных возможностей управления данными. Это одна из его отличительных характеристик. В качестве яркого примера того, что можно достичь с его помощью, ознакомьтесь с руководством «Sending a Localized Newsletter, User by User».

Используем WPGraphQL, если нужна поддержка сообщества

Джейсон Бал проделал отличную работу по сплочению сообщества вокруг WPGraphQL. Потому, если вам нужно решить проблемы с GraphQL API, то вы сможете найти человека, который вам поможет.

В случае с GraphQL API for WordPress сообщество пока еще только создается, и оно, конечно же, сильно далеко от WPGraphQL.

Используем GraphQL API, если нравятся инновации

Я называю GraphQL API for WordPress «перспективным» GraphQL-сервером. Причина в том, что я часто просматриваю список тикетов к спецификации GraphQL и реализую некоторых из них заблаговременно (особенно те, которые мне нравятся или которые я могу поддержать с минимумом затрат).

На сегодняшний день GraphQL API for WordPress поддерживает несколько инновационных возможностей (таких как выполнение нескольких запросов и неймспейсинг схем), и имеются планы по добавлению дополнительных опций.

Используем WPGraphQL, если требуется полная схема

В WPGraphQL имеется полностью размеченная модель данных WordPress, в том числе:

• Записи и страницы.
• Произвольные типы записей.
• Рубрики и метки.
• Произвольные таксономии
• Медиа
• Меню
• Параметры
• Пользователи
• Комментарии
• Плагины
• Темы
• Виджеты

GraphQL API for WordPress с каждым новым релизом добавляет все новые и новые пункты модели данных. На сегодняшний день в список входят:

• Записи и страницы.
• Произвольные типы записей.
• Рубрики и метки.
• Произвольные таксономии
• Медиа
• Меню
• Параметры
• Пользователи
• Комментарии

Если вам нужно получить данные из плагинов, тем или виджетов, то тогда с этим может сейчас справиться только WPGraphQL.

Используйте WPGraphQL, если нужны расширения

WPGraphQL предлагает расширения для многих плагинов, включая Advanced Custom Fields, WooCommerce, Yoast, Gravity Forms.

GraphQL API for WordPress предлагает расширение для Events Manager. В будущем появятся и новые расширения.

Используйте любой из плагинов, если вы хотите создавать блоки для редактора WordPress

Интеграция GraphQL с Gutenberg в настоящий момент ведется и со стороны WPGraphQL, и со стороны GraphQL API for WordPress.

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

В GraphQL API for WordPress используется подход к интеграции с Gutenberg, основанный на стратегии «создать один раз, опубликовать везде». Сначала извлекаются данные блоков из сохраненного контента, после чего используется отдельный тип Block для представления всех блоков. Такой подход позволил бы избежать внедрение серверного реестра.

Решение WPGraphQL можно назвать предварительным, поскольку оно сильно зависит от согласия сообщества на использование серверного реестра. Мы не знаем, будет ли такое согласие.

Для GraphQL API for WordPress решение уже разрабатывается.

Используем GraphQL API, если планируем распространять блоки через плагины

Что я обнаружил: далеко не все плагины (если они вообще есть) используют GraphQL в WordPress.

Не поймите меня неправильно: количество установок WPGraphQL превысило 10000. Однако я считаю, что это в основном установки для работы с Gatsby (чтобы запустить Gatsby) или для работы с Next.js (чтобы запустить один из headless-фреймворков).

Точно так же WPGraphQL имеет массу расширений, как я уже говорил ранее. Однако эти расширения – просто расширения. Это не отдельные плагины.

К примеру, WPGraphQL for WooCommerce зависит от плагинов WPGraphQL  и WooCommerce. Если какой-то из них не установлен, то расширение работать не будет, и это нормально. Но WooCommerce может работать и без WPGraphQL, поэтому в плагине WooCommerce не будет GraphQL.

Насколько я понимаю, нет плагинов, которые бы использовали GraphQL для запуска своей функциональности в WordPress или с целью поддержания своих блоков Gutenberg.

Причина проста: ни WPGraphQL, ни GraphQL API for WordPress не являются частью ядра WP. Таким образом, невозможно полагаться на GraphQL так же, как плагины могут полагаться на WordPress REST API. В итоге плагины, которые предлагают блоки для Gutenberg, могут использовать только REST для получения данных.

Похоже, решение состоит в том, чтобы дождаться появления решения для GraphQL в ядре WP. Но кто знает, сколько времени это займет? Шесть месяцев? Год? Два года? Дольше?

Мы знаем, что добавление WPGraphQL в ядро WordPress потенциально возможно, на это намекал Мэтт Мулленвег. Но сначала должно произойти несколько изменений: повышение минимальной версии WP до 7.1 (требуется как для WPGraphQL, так и для GraphQL API for WordPress), появление четкой дорожной карты для функциональности GraphQL.

Полное редактирование сайтов, которое сейчас в разработке, основано на REST. В фазе 4 разработки Gutenberg должны появиться мультиязычные блоки. Возможно, именно тогда ждать появления и GraphQL?

А теперь, обрисовав проблему, давайте перейдем к готовому решению, которое не требует ожидания.

Я создал следующую реализацию: я взял за основу код GraphQL API for WordPress и несколько урезал его, отбросив все лишнее. Оставил только движок GraphQL и ничего больше (без интерфейса, без произвольных конечных точек, без HTTP кэширования, без контроля доступа и т.д.). Эта версия может распространяться в виде зависимости к Composer, т.е. она может использоваться в плагинах для запуска блоков.

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

Я смог решить проблему с областью видимости GraphQL API for WordPress. В итоге я подготовил версию плагина, которая не будет конфликтовать с каким-либо другим кодом на сайте.

Это означает, что компонент будет работать для любой из следующих комбинаций событий:

• Если плагин является единственным, кто использует компонент на сайте.
• Если GraphQL API for WordPress также установлен на том же самом сайте.
• Если на сайте установлен любой другой плагин, встраивающий этот компонент.
• Если два плагина, которые встраивают компонент, используют одну и ту же версию компонента или его разные версии.

В любой из описанных выше ситуаций плагин будет иметь свой собственный автономный приватный движок GraphQL, на базе которого будут функционировать Gutenberg-блоки (и конфликтов не произойдет).

Этот компонент получит название Private GraphQL API. Работа над ним пока ведется.

Источник: www.smashingmagazine.com