🕸 GraphQLはWordPressをどのように、どこで改善できるか――REST APIを補完する形で

先週末、ブログ記事 🦸🏿‍♂️ Gato GraphQL は PHP 8.0 から 7.1 へのトランスパイルに対応しました を公開しました。

Reddit の /r/php でその記事を共有したところ、コミュニティでは WordPress で GraphQL を使うことの価値、WP REST API との違い、そしてまた別の API を WordPress に持ち込む必要性について、活発な議論が起きました。

ほとんどのコメントは的を射ていると思いますが、いくつかは重要な情報が抜けています。GraphQL は単なるインターフェースではなく、実装でもあります。つまり、異なるプロバイダーの異なる GraphQL サーバーは、それぞれ異なる特性を優先して設計されている可能性があります。そのため、GraphQL が提供するものや、GraphQL エンジンがどのように動作するかについて、常に統一した期待を持つことも、完全に理解することも難しいのです。

たとえば、WordPress と Laravel での GraphQL の体験は異なりますし、異なるサーバー（WPGraphQL と Gato GraphQL）が提供する体験も異なります。

この記事は、Reddit の投稿に寄せられたいくつかのコメントに対する、私自身の見解です。

​

GraphQL vs WP REST API

[とんでもない考えだ] すでに独自の REST API を使っている WordPress の上に GraphQL API を載せるなんて。REST API をそのまま使えばいい。 [出典]

REST API と GraphQL はどちらも同じ目的を果たします。すなわち、アプリケーションが必要とするデータを提供することです。ただし、その達成方法が異なります。REST は特定のデータセットを提供する定義済みのエンドポイントを持つのに対し、GraphQL は必要なデータだけを正確に提供できます。

この動作の違いは、アプリケーションのパフォーマンスに直接影響を与えることがあります。REST では、投稿の一覧と各投稿の著者データを取得する必要がある場合、追加のリクエストを送る必要があります。すべての著者データに対して 1 件の追加リクエスト、もしくは著者ごとに 1 件の追加リクエストが必要になる可能性があります。その間、ウェブサイトの訪問者はページのレンダリングを待っている状態になります。

GraphQL はこの状況を改善します。投稿と著者のすべてのデータを 1 回のリクエストで直接取得でき、ウェブページのレンダリングが速くなります。

{
  posts {
    id
    title
    excerpt
    date
    url
    author {
      id
      name
      url
    }
  }
}Copy

WordPress にすでに REST API があるからといって、それがすべてのタスクに対して常に最適なツールであるとは限りません。もちろん常に使うことはできますが、GraphQL にもアクセスできる場合は、REST より有利な場面ではこの API を使うことを選べますし、その方が良い結果につながります。

​

GraphQL の初期設定の難しさ + リゾルバーの記述

GraphQL の初期設定は REST に比べて指数関数的に高いという議論は確かにあります。関連付けを設定しなければならないという点はその通りです。 [出典]

そして...

あなたもウェブ上のほぼすべての人も見落としているのは、この API 形式を機能させるためにはパーサー（リゾルバー + 型）を書かなければならず、それが REST では存在しない一連の問題を引き起こすという点です。 [出典]

これらのコメントは完全に正確ではありません。なぜなら、WPGraphQL と Gato GraphQL はすでに WordPress のデータモデルを GraphQL スキーマにマッピングしているからです（WPGraphQL は完全に、私のプラグインはほとんど対応済みです）。

つまり、これらのプラグインのいずれかをインストールすれば、リゾルバーを作成したり、エンティティ間の関連付けを設定したりする必要なく、すぐにアプリケーションのデータ取得を開始できます。

確かに、アプリケーション固有のエンティティ（CPT など）からカスタムデータを取得するには、リゾルバーを使ってマッピングする必要があり、それは自分で行う必要があります。ただし、これは REST と変わりません。CPT からカスタムデータが必要なら、そのカスタムデータを取得するための REST エンドポイントを作成する必要があります。カスタムエンドポイントもリゾルバーの一種です。

したがって、リゾルバーの必要性という観点では、REST と GraphQL API はほぼ同じです。

ウェブサイトやドキュメントを見ると、GraphQL の方がセットアップに手間がかかる印象を受けます。この思い込みには一定の根拠があります。

いくつかの理由が考えられます。まず、GraphQL には（少なくとも）2 つの側面があります。

1. それが何であるか、どのように機能するかという概念
2. 実際の実装を提供するサーバー

graphql.org のような GraphQL の公式サイトのドキュメントを見ると、GraphQL の背後にある概念に焦点を当てており、リゾルバーとは何か、なぜ必要なのかについて詳しく説明しています。

これは、Laravel と Lighthouse を使う場合のように、ゼロからアプリケーションを構築する際には役立ちます。その場合、リゾルバーを自分でコーディングする必要があります（ただし、REST エンドポイントも自分で作成する必要があります）。

しかし、WordPress はすでにアプリケーションであり、WPGraphQL と Gato GraphQL はそのソリューションです。この 2 つのプラグインはすでにリゾルバーを作成済みなので、私たちが気にする必要はありません（WP REST API も初期エンドポイントのセットを提供しており、気にする必要がないのと同様です）。

さらに、GraphQL は開発者向けであり、そのドキュメントは開発者に直接語りかけているように見えます。開発者がサーバー側でリゾルバーを作成し、クライアント側ではカスタムクエリでそれらのリゾルバーを使用します。リゾルバーの構築は開発者の仕事であるため、自然に頻繁に登場します。

REST については、必要なデータを提供するエンドポイントはすでに存在しているはず（WP REST API が提供するもの）という期待があります（と私は考えます）。存在しない場合に初めて、カスタムエンドポイントのセットアップを考える必要があります。そのため、REST ではリゾルバーの作成への言及が少なくなります。

つまり、REST と GraphQL はどちらも必要なデータを提供します。ただし、REST はエンドポイントがすでに存在しているべきという静的なアプローチを促し、存在しない場合にのみ気にします。一方、GraphQL はすべてのクエリをカスタムメイドにする動的なアプローチを促し、その完璧なリゾルバーをコーディングできます。

最終的には、REST と GraphQL の間に根本的な違いはなく、要件をどのように満たすべきかという解釈の違いだけがあります。

​

GraphQL の脆弱性 + セキュリティ上の考慮事項

セキュアなインタープリターを書くことは本当に難しいので、いつか GraphQL から大きな脆弱性が生まれるでしょう。 [出典]

そして...

WordPress はすでに巨大なので、常に大きなターゲットになっています。プラグインを追加するだけでリスクが大幅に増加します。そして、WordPress のすべてを文字通り公開しようとするプラグイン（メニューとメニューアイテムを公開するやすべてのユーザーを公開するなどのセキュリティモデルを回避するサンプルコードを含む）は、私には絶対に受け入れられません。テーマ以外の出力は、絶対に必要なものを超えて、できる限り制限されるべきです（私が要求しない限り存在しないべきです）。これがコアに入ることがないことを願います。 [出典]

GraphQL は確かに追加のセキュリティリスクをもたらし、対処が必要です。この懸念には完全に同意します。

ただし、それが GraphQL を WP コアに含める可能性を阻む決定的な問題だとは思いません。さらに、対処が本当に難しいとも思っていません。

必要なのは、GraphQL サーバーが WordPress の既存のセキュリティメカニズムを活用し、開発者がそのメカニズムを使用して、特定のフィールドに適切なユーザーのみがアクセスできるようにすることです。

• ユーザーはログインしているか？
• ユーザーは管理者か？
• ユーザーは何らかのロールや権限を持っているか？
• ユーザーはその投稿の著者か？

この要件を満たすために、Gato GraphQL では Access Control Lists（アクセス制御リスト） を提供しており、各フィールドとディレクティブにアクセスできる人を設定で定義できます。

ただし、ACL だけでは不十分な場合もあり、GraphQL サーバーが追加のセキュリティ対策を提供する必要があります。現在 Gato GraphQL の次期 v0.8 に向けて取り組んでいることをご紹介します。

フィールド posts（投稿データを取得するもの）は認証を必要とせず、ログイン中かどうかに関わらずどのユーザーでもアクセスできます。そのため、セキュリティ上の理由から、公開済みの投稿のみを取得します。

ただし、以下のような状況では下書き・保留中・ゴミ箱の投稿も取得する必要があります。

• 管理者が実行する静的ウェブサイトの構築（サイトのすべてのデータへのアクセスあり）
• 投稿の著者が、編集を続けられるように下書き投稿の一覧を表示する場合

そこで、次のスキームを考えました。投稿を取得するために 3 つのフィールドが用意されます。

• posts: 誰でもアクセス可能で、公開済みの投稿のみ取得できる
• myPosts: 誰でもアクセス可能で、ログイン中のユーザーの投稿のみを任意のステータス（公開済み・下書き・保留中・ゴミ箱）で取得する
• postsForAdmin: 管理者のみアクセス可能で、任意のステータスのすべての投稿を取得する

そして、postsForAdmin はデフォルトで無効になっているため、GraphQL スキーマに表示されません。管理者が明示的に有効にした場合のみ表示されます（おそらく静的サイトの構築にのみ有効化されるでしょう）。

別の状況として、あるフィールドが公開データとプライベートデータの両方を取得できる場合があります。たとえば、フィールド option はテーブル wp_options からデータを取得します。一部のエントリは公開（blogname など）ですが、そうでないもの（admin_email など）もあります。

同様の状況として、フィールド Post.metaValue、User.metaValue などを通じてメタ値を取得する場合があります。たとえば、ユーザーメタには間違いなくプライベートなエントリ wp_capabilities が含まれますが、description は公開されています。そして last_name は、アプリケーションによって公開またはプライベートのどちらにもなりえます。

このデータへのアクセスを安全にするため、プラグインでは設定ページの許可/拒否リストにより、クエリ可能なエントリを指定できるようになります。エントリ全体または正規表現の両方を受け付けます。

許可されたオプションのクエリは機能し、拒否されたオプションは null を返します。

{
  # This option is allowed
  siteName: optionValue(name: "blogname")
  # This optionValue is not allowed
  adminEmail: optionValue(name: "admin_email")
}Copy

GraphQL サーバーによる適切なセキュリティ対策と、開発者の常識があれば、セキュアな GraphQL API の構築は難しくないはずです。

​

GraphQL によるデータベースのダウン

GraphQL は深いリレーショナルクエリを表現できるリッチな構文を持っています。WordPress のようなエコシステムでは、データモデルの拡張性が エンティティ属性値パターン に基づいているため、GraphQL クエリが深く、複雑、または再帰的な場合、データベースに信じられないほどの負荷がかかり、サイトが応答しなくなる可能性があります。WordPress はすでに MySQL/MariaDB インスタンスを限界まで追い込むことで有名です。クエリが適切に記述・認証・レート制限されていなければ、GraphQL を追加することでさらに悪化する可能性があります。 [出典]

データベースのダウンは、GraphQL サーバーにとって深刻な懸念事項です。Gato GraphQL がこのシナリオを回避しようとしている方法をご説明します。

Gato GraphQL は、アーキテクチャ設計によって N+1 問題が発生しないようにしています。エンジンがデータベースからエンティティを読み込む責任を持ち、開発者ではありません。

リゾルバーで接続を解決する際、返される値はオブジェクト自体ではなく、オブジェクトの ID（または ID のリスト）です。たとえば、カスタム投稿の著者を取得するのは次のように行います。

class CustomPostFieldResolver extends AbstractDBDataFieldResolver
{
  private CustomPostUserTypeAPIInterface $customPostUserTypeAPI;
 
  public function getClassesToAttachTo(): array
  {
    return [
      CustomPostFieldInterfaceResolver::class,
    ];
  }
 
  public function getSchemaFieldType(string $fieldName): ?string
  {
    return match($fieldName) {
      'author' => SchemaDefinition::TYPE_ID,
      default => null,
    };
  }
 
  public function resolveValue(
    TypeResolverInterface $typeResolver,
    object $customPost,
    string $fieldName,
    array $fieldArgs = []
  ): mixed {
    switch ($fieldName) {
      case 'author':
        return $this->customPostUserTypeAPI->getAuthorID($customPost);
    }
 
    return null;
  }
 
  public function resolveFieldTypeResolverClass(
    TypeResolverInterface $typeResolver,
    string $fieldName
  ): ?string {
    switch ($fieldName) {
      case 'author':
        return UserTypeResolver::class;
    }
 
    return null;
  }
}Copy

resolveValue から DB エンティティの ID を、resolveFieldTypeResolverClass（クラス UserTypeResolver で表される）からオブジェクトの型を取得することで、GraphQL エンジンはオブジェクトのデータを読み込めます。

データの読み込みに、エンジンは非常に効率的なアルゴリズムを使用しています。これはノードの数ではなく、クエリ内の型の数を n とした時間計算量 O(n) です。

このアルゴリズムがこの効率を達成できるのは、グラフをトラバースするのではなく、データ構造をコンポーネントのスタックに変換するからです。これは解決がはるかに簡単です。（GraphQL の「グラフ」は概念であり、実際の実装ではありません。）

クエリが複数のレベルを持ち、それぞれ多くのエンティティを取得する場合でも、アルゴリズムはかなりよく耐えることができます。たとえば、深さ 10 レベルの次のクエリを実行しても、大きな影響はありません。

{
  posts(pagination: { limit: 10 }) {
    excerpt
    title
    url
    author {
      name
      url
      posts(pagination: { limit: 10 }) {
        title
        tags(pagination: { limit: 10 }) {
          slug
          url
          posts(pagination: { limit: 10 }) {
            title
            comments(pagination: { limit: 10 }) {
              content
              date
              author {
                name
                posts(pagination: { limit: 10 }) {
                  title
                  url
                  comments(pagination: { limit: 10 }) {
                    content
                    date
                    author {
                      name
                      username
                      url
                    }
                  }
                }
              }
            }
          }
        }
      }
    }
  }
}Copy

この効率の例外は、Post.metaValue、User.metaValue、Comment.metaValue、PostTag.metaValue、PostCategory.metaValue（および metaValues フィールド）を通じてメタ値を取得する場合です。WordPress の関数（get_post_meta、get_user_meta など）は 1 度に 1 つの ID のデータを取得するため、各エンティティはメタ値を取得するためにデータベースへの呼び出しを必要とします。その結果、メタ値の解決は型の数ではなくノードの数に応じてスケールします（この点については、元のコメントが的を射ています）。

悪意のある行為者がメタフィールドを使用・悪用することを防ぐために、Gato GraphQL（v0.8）ではこれらのフィールドをデフォルトで無効にして出荷します。管理者が明示的に有効にする必要があり、その際にこれらのフィールドを Access Control List に置くことで、DB が攻撃リスクにさらされることはありません。

レート制限も優れたアイデアであり、将来のリリースでサポートする予定です。

そして、クエリの複雑さの分析と制限の適用（何レベルの深さまで許可するかなど）についても検討しています。GraphQL サーバーは時間計算量 O(n) でクエリを解決するため、ループに関してはそれほど大きな害はありません。ただし、1 つのクエリだけでも DB から無制限の量のデータを取得できる可能性があり、それは回避したいものです。

たとえば、次のシンプルなクエリは 1 回のリクエストで大量のデータを取得します（私のデモサイトにはほんの数百件のレコードしかないため、実行を実演する余裕があります）。

{
  posts000: posts(pagination: { limit: 100 }) {
    ...PostFields
  }
  posts100: posts(pagination: { limit: 100, offset: 100 }) {
    ...PostFields
  }
  posts200: posts(pagination: { limit: 100, offset: 200 }) {
    ...PostFields
  }
  posts300: posts(pagination: { limit: 100, offset: 300 }) {
    ...PostFields
  }
  posts400: posts(pagination: { limit: 100, offset: 400 }) {
    ...PostFields
  }
  posts500: posts(pagination: { limit: 100, offset: 500 }) {
    ...PostFields
  }
  posts600: posts(pagination: { limit: 100, offset: 600 }) {
    ...PostFields
  }
  posts700: posts(pagination: { limit: 100, offset: 700 }) {
    ...PostFields
  }
  posts800: posts(pagination: { limit: 100, offset: 800 }) {
    ...PostFields
  }
  posts900: posts(pagination: { limit: 100, offset: 900 }) {
    ...PostFields
  }
}
 
fragment PostFields on Post {
  id
  title
  content
  date
}Copy

ご覧のとおり、問題を引き起こすためにクエリをネストする必要さえありません。そのため、クエリの複雑さの分析は難しく、有用にするには細かい調整が必要です。

クエリ分析のサポートも追加したいと思っていますが、優先度は高くありません。パーシステッドクエリ や カスタムエンドポイント と Access Control Lists の組み合わせによって、すでに悪意のある行為者を締め出すことができますし、私たち自身が自分の GraphQL サービスを乱用することはない（してはならない！）からです。