Як увімкнути GraphQL в WordPress: WPGraphQL та GraphQL API для огляду WordPress

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

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

До недавнього часу WPGraphQL (значення) був єдиним сервером GraphQL для WordPress. Але потім було більше і GraphQL API для WordPress.

Ці два плагіни служать одній меті: прив’язування API GraphQL до сайту WordPress. Ви можете запитати: чому інший плагін, якщо вже є WPGraphQL? Чи роблять ці два плагіни те ж саме? Або вони для різних ситуацій?

Просто зверніть увагу на наступне: WPGraphQL відмінно справляється з усіма завданнями. Новий плагін не був створений в результаті будь-яких проблем з WPGraphQL.

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

У цій статті я покажу, в якій ситуації WPGraphQL буде найкращим варіантом, і в якій ситуації найкращим варіантом буде GraphQL API для WordPress.

Використання WPGraphQL під час роботи з Гетсбі

Якщо ви розробляєте веб-сайт за допомогою Гетсбі, то у вас є один варіант: WPGraphQL. Творець WPGraphQL Джейсон Болл до недавнього часу працював у самого Гетсбі. З цієї причини WPGraphQL прекрасно працює в поєднанні з додаток джерела для Гетсбі.

Гетсбі отримує всі дані з сайту WordPress, і з цього моменту вся логіка програми лягає на плечі Гетсбі, а не WP. Отже, доповнення до WPGraphQL (наприклад, @stream директиви або @defer) більше не мають значення.

WPGraphQL вже так добре, як Гетсбі потреби.

Використовуйте WPGraphQL, якщо ви працюєте з одним з нових фреймворк без голови

Як згадувалося раніше, останнім часом в просторі без голови WordPress спостерігається сплеск активності – з’ясовуються нові фреймворки, а також стартап-проекти на основі Next.js:

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

Ми використовуємо будь-який плагін, якщо працюємо з Frontity

Фронтальність є React-фреймворк для WordPress. Він дозволяє створювати React-додатки з бекендом на WordPress. Навіть створення записів блогу за допомогою редактора WordPress підтримується з коробки.

Фронтальність базується на REST за замовчуванням, але ви можете використовувати GraphQL для неї підключення вихідного компонента plug-in.

У цьому контексті Frontity функціонує дуже грамотно: додаток source — це інтерфейс для взаємодії з постачальником даних. Зараз єдиним доступним додатком джерела є плагін для WordPress REST API. Однак будь-який розробник може зробити вихідний плагін для WPGraphQL або GraphQL API для WordPress (це підхід, який повинні мати всі фреймворки Next.js в ідеалі).

Висновок: обидва плагіни підходять для роботи з Frontity, але вам потрібно буде підключити їх самостійно.

Використовуйте WPGraphQL, якщо ви створюєте статичний сайт

У перших двох розділах вихід був однаковим: використовуйте WPGraphQL. Однак моя реакція в цих розділах була іншою. Якщо у випадку з Гетсбі я нічого не пошкодував, у випадку з Next.js я відчував брак можливостей.

Чому це так?

Різниця полягає в тому, що Гетсбі є генератором статичних сайтів, а Next.js може генерувати як статичні, так і динамічні (живі) сайти.

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

Навіть якщо Api GraphQL для WordPress пропонує додаткові функції, все це навряд чи якимось чином вплине на генератор статичних сайтів.

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

Використовуйте API GraphQL, якщо нам потрібно використовувати GraphQL на живому сайті (не статичний)

Ситуація, описана вище, змінюється, якщо ми хочемо, щоб GraphQL отримала дані з живого сайту – наприклад, при запуску мобільного додатку або при показі даних в режимі реального часу на сайті (для відображення аналітики і т.д.). Крім того, цей випадок використання буде актуальним при поєднанні статичного та живого підходу на одному сайті.

Скажімо, ми зробили простий статичний блог, використовуючи один з фреймворку Next.js і хочемо дозволити користувачам коментувати публікації в блозі. Як вирішити цю проблему?

Існує два підходи: статичний і живий (або динамічний). Якщо вибрати статичний підхід, то коментарі будуть оброблені разом з рештою сайту. Потім, коли з’являється новий коментар, нам потрібно буде витягнути веб-гак, щоб перебудувати та перерозподілити сайт.

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

У такій ситуації має сенс відображати сайт статично без коментарів, а потім витягувати коментарі з живого сайту і обробляти їх динамічно.

Next.js для цієї мети рекомендується використовувати еукати. Він краще здатний обробляти статичні та динамічні підходи, включаючи підтримку різних виходів для користувачів з різними правами.

Повернутися до обговорення GraphQL: Чому я рекомендую API GraphQL для WordPress при роботі з даними в режимі реального часу? Я роблю це тому, що сервер GraphQL може безпосередньо впливати на додаток – головним чином з точки зору швидкості та безпеки.

У разі чисто статичного підходу сайт WordPress можна залишити приватним (його можна зберігати навіть на ноутбуці розробника), а тому він безпечний. Користувач не буде чекати відповіді від сервера, а тому швидкість тут не грає вирішальної ролі.

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

У цьому відношенні GraphQL API для WordPress має ряд переваг перед WPGraphQL.

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

З точки зору швидкості, постійні запити дозволяють зробити API швидше, оскільки відповідь кешує через кешування HTTP на декількох рівнях, включаючи клієнт, CDN та сервер.

З цих причин API GraphQL для WordPress краще підходить для роботи з живими сайтами.

Використовуйте API GraphQL, якщо ми пропонуємо різні дані для окремих груп користувачів або додатків

WordPress – це універсальна система управління контентом. Залежно від контексту, нам може знадобитися API GraphQL для надання різних даних:

  • Ми пропонуємо певні дані платним користувачам, але не безкоштовно.
  • Ми пропонуємо певні дані в мобільний додаток, але не на сайт.

Щоб передати різні дані, нам потрібно надати різні версії схеми GraphQL.

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

На відміну від цього, API GraphQL для WordPress підтримує цю опцію: він пропонує користувальницькі кінцеві точки, які можуть передавати різні дані в різні контексти, наприклад:

  • /graphql/mobile-додаток та /graphql/веб-сайт,
  • /graphql/pro-користувачі та /graphql/regular-користувачі.

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

Ці функції безпосередньо інтегровані з редактором WordPress (наприклад, Gutenberg). Створення різних діаграм виконується візуально, подібно до створення записів блогу. Тобто створити довільні гр.схеми aphQL можуть використовуватися будь-яким користувачем, а не тільки професійним розробником.

Api GraphQL для WordPress є хорошим варіантом для цього випадку використання.

Ми використовуємо API GraphQL, якщо взаємодіємо зі сторонніми сервісами

GraphQL – це не просто API для отримання та публікації даних. Так само важливо (хоча і часто нехтують), він також може обробляти і змінювати дані. Наприклад, в процесі перенесення їх на якийсь сторонній сервіс (відправка тексту в СТОРОННІЙ API для виправлення граматичних помилок, завантаження зображень в CDN).

Який найкращий спосіб зв’язати GraphQL зі сторонніми сервісами? На мій погляд, це найкраще досягається за допомогою директив, що застосовуються або при створенні або витягу даних (фільтри в WordPress працюють багато в чому таким же чином).

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

На відміну від цього, Api GraphQL для WordPress має надійну підтримку політики. Кожна директива в запиті виконується лише один раз в цілому (на відміну від одного разу на поле або на об’єкт). Ця можливість забезпечує ефективний зв’язок зі сторонніми API шляхом інтеграції API GraphQL з різними сервісами.

Наприклад, нижче наведено запит демонструє, як викликати API Google Translate через директиву @translate переклад заголовків та цитат різних записів з англійської на іспанську. Усі поля для всіх записів перекладаються разом за один виклик.

Api GraphQL для WordPress є хорошим варіантом для цього випадку використання.

Примітка: Двигун, на якому базується API GraphQL для WordPress – GraphQL від PoP – був спеціально розроблений для забезпечення розширених можливостей управління даними. Це одна з його відмінних характеристик. Як перший приклад того, що можна досягти з ним, ознайомтеся з керівництвом .Надсилання локалізованого інформаційного бюлетеня користувачем».

Використовуйте WPGraphQL, якщо вам потрібна підтримка спільноти

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

У випадку GraphQL API для WordPress, спільнота все ще створюється, і це, звичайно, дуже далеко від WPGraphQL.

Використовуйте API GraphQL, якщо вам подобаються інновації

Я називаю GraphQL API для WordPress “перспективним” сервером GraphQL. Причина в тому, що я часто переглядаю список міток специфікації GraphQL і реалізую деякі з них заздалегідь (особливо ті, які мені подобаються або які я можу підтримати з мінімумом витрат).

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

Використовуйте WPGraphQL, якщо вам потрібна повна схема

WPGraphQL має повністю маркований модель даних WordPress, включаючи:

  • Записи та сторінки.
  • Довільні типи записів.
  • Категорії та теги.
  • Довільні таксономії
  • ЗМІ
  • Меню
  • Параметри
  • Користувачів
  • Коментарі
  • Компоненти plug-in
  • Темами
  • Віджети

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

  • Записи та сторінки.
  • Довільні типи записів.
  • Категорії та теги.
  • Довільні таксономії
  • ЗМІ
  • Меню
  • Параметри
  • Користувачів
  • Коментарі

Якщо вам потрібно отримати дані з плагінів, тем або віджетів, то впоратися з цим зараз може тільки WPGraphQL.

Використовуйте WPGraphQL, якщо вам потрібні розширення

WPGraphQL пропонує розширення для багатьох плагінів, включаючи розширені користувацькі поля, WooCommerce, Yoast, Gravity Forms.

Api GraphQL для WordPress пропонує розширення для менеджера подій. У майбутньому будуть нові розширення.

Використовуйте будь-який з плагінів, якщо ви хочете створити блоки для редактора WordPress

Інтеграція GraphQL з Гутенбергом в даний час ведеться як WPGraphQL, так і GraphQL API для WordPress.

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

Api GraphQL для WordPress використовує інтеграційний підхід Гутенберга, заснований на стратегії “створити один раз, опублікувати скрізь”. Спочатку з збереженого вмісту витягуються дані блоку, а потім для представлення всіх блоків використовується окремий тип Block. Такий підхід уникне введення серверної реєстру.

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

Для GraphQL API для WordPress вже розробляється рішення.

Ми використовуємо API GraphQL, якщо плануємо розподіляти блоки через плагіни

Те, що я знайшов, що не всі плагіни (якщо такі є) використовують GraphQL в WordPress.

Не захищай мене неправильно: інсталяції wpGraphQL перевищили 10 000. Тим не менш, я вважаю, що це в основному установки для роботи з Гетсбі (для запуску Гетсбі) або для роботи з Next.js (для запуску одного з безжйних рамок).

Аналогічним чином, WPGraphQL має багато розширень, як я вже говорив раніше. Однак ці розширення є просто розширеннями. Це не окремі плагіни.

Наприклад, WPGraphQL для WooCommerce залежить від плагінів wpGraphQL та WooCommerce. Якщо один з них не встановлений, то розширення не буде працювати, а це нормально. Але WooCommerce може працювати без WPGraphQL, тому плагін WooCommerce не матиме GraphQL.

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

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

Здається, що рішення полягає в тому, щоб дочекатися, коли рішення GraphQL з’явиться в ядрі WP. Але хто знає, скільки часу це займе? Півроку? рік? Два роки? Довше?

Ми знаємо, що додавання WPGraphQL до ядра WordPress потенційно можливе, як натякнув Метт Малленвег. Але спочатку має бути кілька змін: підвищення мінімальної версії WP до 7.1 (потрібно як для WPGraphQL, так і для graphQL API для WordPress), поява чіткої дорожньої карти для функціональності GraphQL.

Повне редагування сайту, яке зараз знаходиться в розробці, базується на REST. У фазі 4 розробки Гутенберга повинні з’явитися багатомовні блоки. Можливо, саме тоді нам слід чекати, коли з’явиться GraphQL?

А тепер, окресливши проблему, перейдемо до готового рішення, яке не вимагає очікування.

Я створив наступну реалізацію: я взяв api GraphQL для коду WordPress за основу і дещо обріїв його, відкинувши всі зайві. Залишив тільки рушій GraphQL і більше нічого (ні інтерфейсу, ні довільних кінцевих точок, ні кешування HTTP, ні контролю доступу і т.д.). Ця версія може бути поширена як залежність від Composer, тобто вона може бути використана в плагінах для запуску блоків.

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

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

Це означає, що компонент буде працювати для будь-якої з наступних комбінацій подій:

  • Якщо плагін є єдиним, хто використовує компонент на сайті.
  • Якщо API GraphQL для WordPress також встановлений на тому ж сайті.
  • Якщо на сайті встановлено будь-який інший компонент, який вбудовує цей компонент.
  • Якщо два плагіни, що вбудовують компонент, використовують однакову версію компонента або його різні версії.

У будь-якій з описаних вище ситуацій плагін матиме власний автономний приватний рушій GraphQL, на базі якого будуть функціонувати блоки Gutenberg (і конфліктів не буде).

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

джерело: www.smashingmagazine.com

Прокоментувати

Ваша e-mail адреса не оприлюднюватиметься. Обов’язкові поля позначені *