Как заставить GraphQL работать в WordPress

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

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

До недавнего времени WPGraphQL был единственным сервером GraphQL для WordPress. Но теперь доступен еще один такой плагин: GraphQL API для WordPress, автором которого является я.

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

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

Я создал GraphQL API для WordPress, потому что работал над механизмом для эффективного извлечения данных , который оказался очень подходящим для GraphQL. Тогда я сказал себе: «Почему бы и нет?» И построил его. (А также еще пара причин.)

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

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

Используйте WPGraphQL, если: с помощью Gatsby

Если вы создаете веб-сайт с помощью Gatsby, у вас есть только один выбор: WPGraphQL.

Причина в том, что только WPGraphQL имеет исходный плагин Gatsby для WordPress. Кроме того, создатель WPGraphQL, Джейсон Бал, до недавнего времени работал в Gatsby, поэтому мы можем полностью доверять тому, что этот плагин удовлетворит потребности Gatsby.

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

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

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

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

• Колби Файок создал Next.js WordPress Starter.
• WebDevStudios запустила собственный Next.js WordPress Starter.
• WP Engine создала Headless WordPress Framework, которая позволяет его службе размещать и развертывать безголовые веб-сайты WordPress.

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

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

Я немного надеюсь, что любой из этих фреймворков создаст такой интерфейс. Я спросил об этом на доске обсуждений Headless WordPress Framework, и мне сказали, что это можно рассмотреть. Я также задал вопрос на доске обсуждений Next.js WordPress Starter от WebDevStudios, но, увы, мой вопрос был немедленно удален без ответа. (Не обнадеживает, правда?)

Так что WPGraphQL это тогда, сейчас и в обозримом будущем.

Используйте любой из них (или ни один из них), если: использование Frontity

Frontity — это фреймворк React для WordPress. Это позволяет вам создавать приложение на основе React, которое управляется в серверной части через WordPress. Даже создание сообщений в блоге с помощью редактора WordPress поддерживается из коробки.

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

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

Вывод : ни WPGraphQL, ни API GraphQL не предлагают никаких преимуществ перед другими для работы с Frontity, и оба требуют некоторых первоначальных усилий для их подключения.

Используйте WPGraphQL, если: Создание статического сайта

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

Почему это?

Разница в том, что хотя Gatsby является исключительно генератором статических сайтов, Next.js может работать как со статическими, так и с живыми веб-сайтами.

Я упомянул, что WPGraphQL уже достаточно хорош для Гэтсби. Это утверждение на самом деле можно расширить: WPGraphQL уже достаточно хорош для любого генератора статических сайтов . Как только генератор статического сайта получает данные с веб-сайта WordPress, он в значительной степени согласуется с WordPress.

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

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

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

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

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

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

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

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

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

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

Для чисто статического веб-сайта веб-сайт WordPress может оставаться закрытым (он может даже находиться на ноутбуке разработчика), так что это безопасно. И пользователь не будет ждать ответа от сервера, так что скорость не обязательно имеет критическое значение.

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

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

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

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

Эти причины делают GraphQL API для WordPress более подходящим для работы с живыми веб-сайтами.

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

WordPress — это универсальная система управления контентом, способная управлять контентом для нескольких приложений и доступная для разных типов пользователей.

В зависимости от контекста нам могут понадобиться API-интерфейсы GraphQL для предоставления различных данных, таких как:

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

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

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

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

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

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

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

Я считаю, что GraphQL API для WordPress предоставляет естественное решение для этого варианта использования.

Используйте GraphQL API, если: Взаимодействие с внешними службами

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

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

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

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

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

GraphQL API для WordPress — естественный выбор для этого варианта использования.

Примечание . На самом деле механизм, на котором основан GraphQL API для WordPress, GraphQL от PoP, был специально разработан для обеспечения расширенных возможностей манипулирования данными. Это одна из его отличительных особенностей. Крайний пример того, чего он может достичь, можно найти в руководстве «Отправка локализованного информационного бюллетеня, пользователь за пользователем».

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

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

В моем случае я все еще стремлюсь создать сообщество пользователей вокруг GraphQL API для WordPress, и это, конечно, далеко не так, как у WPGraphQL.

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

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

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

Используйте WPGraphQL, если: вам нужна полная схема

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

• посты и страницы,
• настраиваемые типы сообщений,
• категории и теги,
• пользовательские таксономии,
• СМИ,
• меню,
• настройки,
• пользователи,
• Комментарии,
• плагины,
• темы,
• виджеты.

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

• посты и страницы,
• настраиваемые типы сообщений,
• категории и теги,
• пользовательские таксономии,
• СМИ,
• меню,
• настройки,
• пользователи,
• Комментарии.

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

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

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

GraphQL API для WordPress предлагает расширение для Events Manager, и оно будет добавляться после выпуска версии 1.0 плагина.

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

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

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

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

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

Для GraphQL API для WordPress решение будет полностью зависеть от самого себя, и это уже действительно работа.

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

Используйте API GraphQL, если: Распределение блоков через плагин

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

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

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

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

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

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

По-видимому, решение состоит в том, чтобы дождаться добавления решения GraphQL (скорее всего, WPGraphQL) в ядро ​​​​WordPress. Но кто знает, сколько времени это займет? Шесть месяцев? Год? Два года? Дольше?

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

(Полное редактирование сайта, которое в настоящее время находится в стадии разработки, основано на REST. А как насчет следующей важной функции, многоязычных блоков, которая будет рассмотрена в фазе 4 Гутенберга? Если не это, то какая функция будет?)

Объяснив проблему, давайте рассмотрим потенциальное решение — такое, которое не нужно ждать!

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

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

К счастью, я недавно решил область GraphQL API для WordPress. Итак, я знаю, что могу полностью охватить его, создав версию, которая не будет конфликтовать с каким-либо другим кодом на веб-сайте.

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

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

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

Этот компонент, который будет называться Private GraphQL API , должен быть готов через несколько недель. (Я уже начал работать над этим.)

Следовательно, я рекомендую, если вы хотите использовать GraphQL для управления блоками Gutenberg в своем плагине, подождите несколько недель, а затем проверьте GraphQL API для младшего брата WordPress, Private GraphQL API.

Заключение

Несмотря на то, что у меня есть шкура в игре, я думаю, что мне удалось написать статью, которая в основном объективна.

Я честно указал, почему и когда вам нужно использовать WPGraphQL. Точно так же я был честен, объясняя, почему API GraphQL для WordPress лучше, чем WPGraphQL, в некоторых случаях использования.

В общих чертах мы можем резюмировать следующим образом:

• Станьте статичным с WPGraphQL или работайте с GraphQL API для WordPress.
• Будьте осторожны с WPGraphQL или инвестируйте (с потенциально достойным вознаграждением) в GraphQL API для WordPress.

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

Полезные ссылки

• WPGraphQL: документация, страница загрузки, репозиторий кода
• GraphQL API для WordPress: документация, страница загрузки, репозиторий кода
• «Семинар по интеграции Gatsby с WordPress»
  Видео на YouTube с демонстрацией WPGraphQL
• «Введение в GraphQL API для WordPress»
  Видео на YouTube с демонстрацией GraphQL API для WordPress