🙅‍♀️ Почему GraphQL не должен быть в ядре WordPress

Да, вы правильно прочитали этот заголовок. Несмотря на то что я сам являюсь создателем сервера GraphQL для WordPress, я изменил своё мнение относительно того, должен ли WordPress поставляться с GraphQL или нет.

Ещё не так давно я считал, что GraphQL должен быть в ядре WordPress. Логика состояла в том, что участники проекта тратили время и усилия на реализацию функциональности для WP REST API (пакетные операции), которая является нативной для GraphQL.

Однако недавно я узнал кое-что новое, что заставило меня пересмотреть свою позицию, и теперь я считаю, что WordPress не должен поставляться с GraphQL из-за связанных с этим рисков.

Вот мои аргументы.

​

1. Это не удовлетворяет правилу 80/20

Исторически та или иная функциональность добавляется в ядро WordPress только в том случае, если она удовлетворяет правилу 80/20, то есть 80% или более пользователей будут её использовать.

Будет ли это так с GraphQL? Думаю, ответ — «нет», основываясь на прецеденте введения WP REST API в WordPress 4.7.

В своём докладе WordPress as Data, 5 Years In К. Адам Уайт (главный руководитель начальной разработки и релиза WP REST API) рассказал, что участники проекта ожидали широкого использования REST API после его выпуска вместе с ядром. Но этого не произошло: разработчики продолжали создавать сайты на WordPress так же, как и раньше, почти не обращая внимания на «headless» или REST API.

Ситуация изменилась лишь позднее, с появлением редактора Gutenberg в WordPress 5.0, основанного на REST API. Может ли тогда Gutenberg обосновать добавление GraphQL в ядро WordPress?

​

2. Headless уже реализован через REST API

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

Однако WordPress уже имеет REST API, и всё, что можно сделать с GraphQL, можно сделать и с REST. Внедрение GraphQL в дополнение к REST похоже на покупку BMW, когда вы уже ездите на Toyota. Вы доберётесь до цели быстрее, и процесс вождения будет приятнее. Но обе машины доставят вас туда, куда вы хотите попасть.

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

​

3. Темы и плагины WordPress могут использовать webonyx/graphql-php

Публичные плагины не могут требовать, чтобы сайт устанавливал WPGraphQL или Gato GraphQL для работы плагина, поскольку это уменьшит их потенциальный охват. Поэтому публичные плагины не могут полагаться на GraphQL, и это действительно жаль.

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

Но затем несколько недель назад был выпущен плагин WordPress, основанный на GraphQL. Мне было интересно, как автор это сделал: использует ли он WPGraphQL или Gato GraphQL под капотом? Я проверил его исходный код и оказалось, что он напрямую использует webonyx/graphql-php!

Это интересное решение, которое демонстрирует, что при некотором усилии разработчики уже сейчас имеют доступ к GraphQL для своих тем и плагинов.

Этот плагин использует GraphQL для получения собственных сущностей данных, а не данных WordPress (посты, пользователи, комментарии и т.д.). Следовательно, ему не нужно воссоздавать схему GraphQL, содержащую модель данных WordPress, как это делают WPGraphQL и Gato GraphQL (и в конечном счёте GraphQL API Private). Поэтому использование webonyx/graphql-php вполне обоснованно.

​

4. GraphQL несёт дополнительные риски

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

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

GraphQL подвержен следующим векторам атак (среди прочих):

• Единый endpoint предоставляет доступ ко всей информации сайта, поэтому частные данные могут быть непреднамеренно раскрыты.
• Queries могут быть очень сложными и способны перегрузить веб-серверы и серверы баз данных.
• Одна и та же мутация может выполняться несколько раз в одном запросе, а несколько queries могут выполняться вместе в одном запросе, что позволяет злоумышленникам пытаться получить доступ к бэкенду, перебирая множество комбинаций логин/пароль.

Эти атаки могут нанести реальный ущерб. В своём выступлении Damn GraphQL - Defending and Attacking APIs исследователь кибербезопасности Долев Фархи сумел вывести из строя сайт WordPress менее чем за 30 секунд, атаковав endpoint WPGraphQL пакетом сложных queries.

Команда WPGraphQL немедленно исправила проблему. Но как мы можем быть уверены, что никакой другой эксплойт не произойдёт? (Я имею в виду не только WPGraphQL, но и Gato GraphQL.)

Эти атаки возможны с GraphQL, но не с REST, потому что GraphQL мощнее, чем REST. В то время как в REST запрос определяется заранее и хранится на сервере, в GraphQL он предоставляется клиентом во время выполнения (если только не используются persisted queries).

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

​

Подводя итог

Чтобы быть точным: я не призываю отказаться от использования GraphQL в WordPress (конечно, нет!), а к ответственному использованию GraphQL. GraphQL — мощный инструмент, а значит, опасный. При использовании GraphQL нам необходимо быть уверены, что мы знаем, что делаем.

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