🙅‍♀️ GraphQLをWordPressコアに含めるべきでない理由

そうです、タイトルを正確に読みました。私自身がWordPress向けのGraphQLサーバーの作者であるにもかかわらず、WordPressがGraphQLを同梱すべきかどうかという点で考えが変わりました。

少し前まで、私はGraphQLをWordPressコアに含めるべきだと信じていました。その理由は、コントリビューターたちがWP REST APIのために（バッチ操作などの）機能の実装に時間と労力を費やしていたからです。これはGraphQLが本来持っている機能です。

しかし最近、新しい情報を知り、再び考え直すことになりました。今では、追加されるリスクのために、WordPressはGraphQLを同梱すべきではないと考えています。

以下がその理由です。

​

1. 80/20ルールを満たさない

歴史的に、特定の機能がWordPressコアに追加されるのは、80/20ルールを満たす場合のみです。つまり、ユーザーの80%以上がその機能を使用する場合です。

GraphQLの場合はどうでしょうか？WordPress 4.7へのWP REST API導入という前例をもとに考えると、答えは「ノー」だと思います。

K. Adam White（WP REST APIの初期開発とリリースの主要リード）は、彼のトーク WordPress as Data, 5 Years In の中で、コントリビューターたちはREST APIがコアとともにリリースされたら広く使われると期待していたと述べています。しかし、それは起こりませんでした。開発者たちは以前と同じようにWordPressサイトを作り続け、「ヘッドレス」やREST APIにはほとんど注目しませんでした。

状況が変わったのは後になってからで、WordPress 5.0でREST APIを基盤とするGutenbergエディターが導入されたときでした。では、GutenbergはGraphQLをWordPressコアに追加することを正当化できるでしょうか？

​

2. ヘッドレスはすでにREST APIで満たされている

WordPressエディターはネイティブのGraphQLサーバーで強化でき、ブロック開発者が（既存のREST APIに加えて）GraphQLを使用してブロックのデータを取得できるようになります。さらに、テーマやプラグインがGraphQLを使って独自の内部機能を強化することもできます。これらはGraphQLをWordPressコアに追加する強い理由です。

しかし、WordPressにはすでにREST APIがあり、GraphQLでできることはRESTでもできます。RESTに加えてGraphQLを導入することは、すでにトヨタに乗っているのにBMWを買うようなものです。目的地にはより早く着き、ドライビング体験もより魅力的になるでしょう。しかし、どちらの車も行きたい場所に連れて行ってくれます。

GraphQLは以前は利用できなかった機能を提供するわけではないため、コアへの組み込みは完全には正当化されません。GraphQLはAPIとのインタラクション体験を確かに向上させますが、これはプラグインの領域として十分に考えられます。

​

3. WordPressのテーマとプラグインはwebonyx/graphql-phpを使用できる

公開プラグインは、プラグインを使用するためにWPGraphQLやGato GraphQLをインストールするようウェブサイトに要求することができません。それでは潜在的なリーチが減ってしまうからです。そのため、公開プラグインはGraphQLに依存できません。これは本当に残念なことです。

私はこの問題について真剣に考え、潜在的な解決策を考えました。それが GraphQL API Private です。これはプラグインが自分自身の用途のために組み込むことができる自己完結型のGraphQLエンジンで、Composerパッケージとして配布されます。（このプロジェクトにはまだ着手していません。）

しかしその数週間後、GraphQL搭載のWordPressプラグインがリリースされました。作者はどのようにしたのか気になりました。WPGraphQLやGato GraphQLを内部で使っているのでしょうか？そこでソースコードを確認したところ、なんと直接webonyx/graphql-phpを使用していました！

これは興味深い解決策で、少しの努力で開発者が現在もテーマやプラグインのためにGraphQLにアクセスできることを示しています。

このプラグインはGraphQLを使ってWordPress（投稿、ユーザー、コメントなど）のデータエンティティではなく、自身のデータエンティティを取得しています。そのため、WPGraphQLやGato GraphQL（そして最終的にはGraphQL API Private）が行っているようなWordPressデータモデルを含むGraphQLスキーマを再構築する必要がありません。そういった意味で、webonyx/graphql-phpに依存することは理にかなっています。

​

4. GraphQLには追加のリスクがある

上記の3つの問題はいずれも、GraphQLはWordPressを強化するものの、それほど説得力があるわけではないことを示しています。この観点からすれば、依然としてGraphQLをWordPressコアに追加することはでき、その恩恵を受けるか、何も起こらないかのいずれかです。

しかし、この4番目の問題は、GraphQLがWordPressにそれほど価値を追加しないのであれば、追加のリスクがあるため追加すべきではないことを示唆しています。

GraphQLは（他のものに加えて）以下の攻撃ベクトルに対して脆弱です：

• 単一のエンドポイントがウェブサイトのすべての情報へのアクセスを提供するため、意図せずプライベートデータが公開される可能性があります。
• クエリが非常に複雑になり、ウェブサーバーとデータベースサーバーに過大な負荷をかける可能性があります。
• 同じmutationを1つのクエリで複数回実行でき、複数のクエリを1つのリクエストでまとめて実行できるため、攻撃者がユーザー名とパスワードの多くの組み合わせを試してバックエンドへのアクセスを試みることができます。

これらの攻撃は本当に深刻なダメージを与える可能性があります。サイバーセキュリティ研究者のDolev Farhiは、プレゼンテーション Damn GraphQL - Defending and Attacking APIs の中で、複雑なクエリのバッチでWPGraphQLエンドポイントを攻撃することで、30秒以内にWordPressサイトをダウンさせることに成功しました。

WPGraphQLチームはすぐに問題を修正しました。しかし、他のエクスプロイトが発生しないことをどうやって確認できるでしょうか？（WPGraphQLだけでなく、Gato GraphQLも含めて）

これらの攻撃はGraphQLでは起こり得ますが、RESTでは起こりません。なぜなら、GraphQLはRESTよりも強力だからです。RESTではクエリは事前に定義されサーバーに保存されますが、GraphQLでは（persisted queriesを使用しない限り）実行時にクライアントから提供されます。

ウェブサイト管理者がエンドポイントへのアクセス権者や公開するデータの設定を怠ると、問題が発生する可能性があります。技術に詳しくない何百万もの人々が使用しているWordPressの人気を考えると、問題が発生する可能性は非常に高いです。

​

まとめ

念のため言っておきますが、私はWordPressでGraphQLを使わないよう主張しているのではありません（もちろん、そんなことは言っていません！）。責任を持ってGraphQLを使用することを主張しているのです。GraphQLは強力であり、それは危険でもあります。GraphQLを使用する際には、自分が何をしているかをしっかり理解している必要があります。

GraphQLをWordPressコアに組み込むと、多くの人々の手に渡ることになり、そのうちの多くはそのリスクを認識せず、適切な対策を講じないでしょう。それは潜在的な災害の原因になります。そのため、今の私の意見では、それは避けるべきだと考えます。