🥊 Gato GraphQL vs WPGraphQL: 対決！

2024年05月01日更新: Gato GraphQL vs WPGraphQL の比較をご覧ください。

皆さんんんんんんんんんんんん。

試合の告知

世紀の一戦が行われるMGMグランド・ガーデン・アリーナへようこそ！今夜、私たちは歴史を作ります。2人の若きファイターがリングで向かい合い、これまで懸命に戦ってきたプライズを争います：

「WordPressのGraphQL」世界チャンピオン 🏆 の称号を手にするために

右コーナーには、現チャンピオンがいます。まだ4歳ですが、すでに豊富な経験を持ち、最近バージョン1.0に達してwp.orgディレクトリに公開されており、大衆の間で非常に人気があります。

🥁 盛大な 🥁 拍手で 🥁 お迎え 🥁 くださいいいい 🥁 ...... WPGraphQL！

現チャンピオン、WPGraphQL

左コーナーには、挑戦者がいます。世に出てまだわずか1ヶ月ですが、エネルギッシュで野心的であり、初日から強さを見せつけています。今日の対決を求めてきたのは彼自身でした。今夜がチャンスであり、世界中が注目しています。

🥁 盛大な 🥁 拍手で 🥁 お迎え 🥁 くださいいいい 🥁 ...... Gato GraphQL！

挑戦者、Gato GraphQL

今夜、2人の選手は初めて顔を合わせ、12ラウンドの試合を行います。リング中央でポジションについてゴングを待ちながら、互いを観察し、相手の弱点を探ろうとしています。しかし、両者は自信に満ちた表情を見せるのみです。

2人の勇者が互いを研究する

どちらが勝つのでしょうか？WPGraphQLは支持者たちのサポートに基づいて優位を維持するのでしょうか？それとも新参者のGato GraphQLが、気づかないうちに大衆を驚かせ、群衆を自分の側に引き込むのでしょうか？

今夜、皆さん、私たちは答えを知ることになります。

賭けをどうぞ。そして試合を楽しんでください！

🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣

最近、私のプラグインであるGato GraphQLとWPGraphQLの違いについて説明してほしいというリクエストをいただきました。

両プラグインはWordPress向けのGraphQLサーバーですので、同じ目的を果たします。しかし、内部的には異なる特性を持っており、それによって一方が特定の要件を満たすのに優れている場合があります。

自分のプラグインへの偏りがあるのは認めますが、GraphQLとWordPressの両方にとって重要だと考えるトピックに基づいて、公正な比較を行うよう努めました。（読者が別のトピックについての比較を希望される場合は、喜んで対応します。）

この比較は網羅的ではありません。たとえば、同じGraphQLクエリを両サーバーで解決する速度を測定するベンチマークも行いたいと思っています。（読者がこの提案に興味を持たれた場合、今後の記事で取り上げることができます。）

比較を4つの主要な領域に分けました：人気度、コードスタイルと標準、重要な問題、そしてスコープの拡大。それぞれに3つの項目があり、合計12の「ラウンド」となります。最後に審判が判決を下し、チャンピオンが決まります。

以下をクリックして特定のトピックに直接ジャンプしてください：

人気度
コードスタイルと標準
インターミッション
重要な問題
スコープの拡大
判決！

🔔 ゴン 🔔 ゴン 🔔 ゴーーーーン...

開始のゴングが鳴りました...

試合が始まりました！

コードスタイルと標準

コードの話をしましょう！

GraphQLを使用しているなら、おそらくヘッドレスWordPressを行い、JavaScriptフレームワークを使用してウェブサイトをレンダリングしていることでしょう。それはモダンなパラダイムです。さらに、WordPressは古いCMSかもしれませんが、GraphQLはサイトからデータにアクセスするためのモダンなインターフェースです。したがって、あなたは優れた開発者であり、エレガントなコードを書くことに熱心で、最適でないソリューションを受け入れないと安全に仮定できます。

これら2つのプラグインのコード（それ自身のコードベースと、カスタム実装に期待されるコード）はどれほどエレガントでしょうか？

ラウンド4: PHPの要件

WPGraphQLもGato GraphQLも、PHP 7.1以上を必要とします。

しかし、違いがあります：Gato GraphQLは実際にはPHP 7.4を使用してコーディングされており、その後本番環境ではPHP 7.1にトランスパイルされます。

そのため、Gato GraphQLのコーディングははるかに快適です：object型、型付きプロパティ、アロー関数などの新しいPHP機能を使用できます。PHP 8.0のサポートが追加されると（Landoの新バージョンがリリースされたとき）、ユニオン型、match式なども使用できるようになります。

ラウンドの勝者：Gato GraphQL。

Gato GraphQLが爪痕を残す！

ラウンド5: コーディング手法

まずWPGraphQLから始めましょう。wp-graphql/wp-graphqlリポジトリを見ると、私には際立つものがあります：

リポジトリに保存されたvendorフォルダー

ズームインすると：

vendorフォルダーの内容

申し訳ありませんが、私にはこれに対する反応が一つしかありません：

人生で多くのことは許せるが、これは許せない

Composerのvendorフォルダーをリポジトリにコミットすることは悪い習慣であり、Composerはそれを明示的に非推奨としています。

この問題を修正することは難しくありません（GitHub actionsに基づく方法を説明したこともあります）ので、なぜそこにあるのか不思議に思います。

このラウンドでは、WPGraphQLは自分自身を打っていると言えるでしょう！

痛い！

続けましょう。WPGraphQLの開発には、非常に広範なフック（アクションとフィルター）のコレクションを知る必要があります。WPGraphQLの開発者リファレンスを見ると、その規模がわかります。

アクションの一覧のスクリーンショットを撮るために、ブラウザを50%まで縮小しなければなりませんでした：

WPGraphQLを拡張するためのアクションフック

フィルターの一覧については、30%（Firefoxがサポートする最小値）まで縮小しても、一覧全体を表示できませんでした：

WPGraphQLを拡張するためのフィルターフック

GatoGraphQL/GatoGraphQLリポジトリ（Gato GraphQLなどのプロジェクトを含むモノリポ）に切り替えましょう。

コードのいくつかの特徴を挙げます：

✅ 標準PSR-1、PSR-4、PSR-12に準拠。

✅ すべてのコードは複数のアトミックなパッケージに分割されており、それらすべて（プラグインで100以上、プロジェクト全体で200以上）が同じモノリポにホストされています。

✅ Composerを使用してすべての依存関係を管理。

✅ アプリケーション内のすべてのサービスを管理するためにSymfony Dependency Injectionを使用。新しいタイプリゾルバー、フィールドリゾルバー、ディレクティブリゾルバーを登録するには、コンテナに新しいサービスを登録するだけです。

✅ すべてのクラスがサービスであり、Symfony Dependency Injectionがアプリケーション全体のオートワイヤリングを処理します。

✅ 基盤となるGraphQLサーバーはCMSに依存しません。Gato GraphQLはWordPress向けのコントラクトを実装し、少々カスタムロジック（クライアントの提供など）を追加しています。

WordPress固有のコードはコード全体のわずか約10%です。この10%を別のフレームワークやCMS（Laravel/Drupalなど）向けに複製することで、それらのGraphQLサーバー実装を提供できます。

✅ CMSに依存しない結果として、リゾルバーのコーディングは再利用可能なサービスに支えられた汎用的なビジネスロジックをコーディングすることを意味します。WordPressコードの観点では考えず、その技術的負債を処理する必要はほとんどありません。

✅ 同様に、GraphQLスキーマはWordPressデータモデルの1:1のレプリカではなく、WordPressがデータ層に蓄積した技術的負債を迂回し、クリーンなインターフェースを提供します。

✅ GraphQLのN+1問題は、アーキテクチャ設計により、開発者に負担をかけることなく発生しません。

✅ サーバーは単なるGraphQLサーバーではありません：実際にはAPIサーバーであり、単一のソースオブトゥルースから他のフォーマットや仕様（REST等）でレスポンスを出力できます。（これについてはラウンド11で詳しく説明します。）

✅ vendorディレクトリはコミットされません。代わりに、ソースコードは配布コード（WordPressサイトにインストールするための最終プラグイン）に変換され、GitHub actionsを通じて、vendorフォルダーを含むdistリポジトリにデプロイされます。

✅ 配布コードを生成する際、PHP-Scoperでスコープが設定され、PHP 7.4コードを含むソースコードはPHP 7.1にトランスパイルされます。

✅ スコーピングを解決したため、プラグインは任意のサードパーティ依存関係を利用できます。現在、SymfonyのDependencyInjection、Cache、Dotenv、Guzzle（外部APIとの連携）、The LeagueのPipelineなどを使用しています。

これは現在だけでなく将来にとっても重要です：Packagistリポジトリから任意の依存関係を使用できると確信できるので、車輪を再発明する必要がありません。

✅ フィールドはタイプに登録されており、GraphQLスキーマを簡単に拡張できます。

ラウンドの勝者：Gato GraphQL（大差で、と言っても構わないでしょう）。

激しいラウンドの後、WPGraphQLは少し休息が必要

ラウンド6: スキーマの拡張

GraphQLスキーマにフィールドを追加してみましょう。

WPGraphQLのチュートリアルに従います。提案されているコードは以下の通りです。アクションフックを宣言して配列を宣言する関数を実行します。フィールドの説明とその解決は、配列内で提供されます：

add_action( 'graphql_register_types', function() {
 
	register_graphql_field( 'RootQuery', 'myNewField', [
		'type' => 'String',
		'args' => [
			'myArg' => [
				'type' => 'String',
        'description' => __( 'Description for how the argument will impact the field resolver', 'your-textdomain' ),
			],
		],
		'resolve' => function( $source, $args, $context, $info ) {
			if ( isset( $args['myArg'] ) ) {
				return 'The value of myArg is: ' . $args['myArg'];
			}
			return 'test';
		},
	]);
 
});

この例はできる限りシンプルなものです：リゾルバーは基本的に何もしません。それでも、コードを見て何をしているのかを一目で理解するのに苦労します。皮肉ではありません：エディターでのそのコードのすべての色が私の注意を奪い合っています。さらに、関心の分離がなく、コードはあまり再利用可能ではなさそうです。

したがって、アプリケーションを開発しながら、コードを読みやすく、再利用可能で、バグのないものにするのは開発者（つまりあなた）次第です；ライブラリ自体はこの点ではあまり助けにならないようです。

私はこのスタイルを「ADD」：Array-Driven Developmentと呼んでいます。私はそれのファンとは言えません。

（WPGraphQLに対して公平に言えば、これは標準的なコーディング手法であり、基盤エンジンのwebonyx/graphql-phpでも使用されているものです。）

Gato GraphQLでは、すべてのコードがSOLIDです。GraphQLスキーマにフィールドを登録するには、FieldResolverInterfaceインターフェースを実装するクラスを作成し（実際には、多くのメソッドがすでに実装されているAbstractSchemaFieldResolverを拡張し）、コンテナに登録します。

たとえば、このコードはUser型にusername、email、urlフィールドを提供します：

class UserFieldResolver extends AbstractSchemaFieldResolver
{
  public static function getClassesToAttachTo(): array
  {
    return [
      UserTypeResolver::class,
    ];
  }
 
  public static function getFieldNamesToResolve(): array
  {
    return [
      'username',
      'email',
      'url',
    ];
  }
 
  public function getSchemaFieldDescription(TypeResolverInterface $typeResolver, string $fieldName): ?string
  {
    $descriptions = [
      'username' => $this->translationAPI->__("User's username handle", "users"),
      'email' => $this->translationAPI->__("User's email", "users"),
      'url' => $this->translationAPI->__("URL of the user's profile in the website", "users"),
    ];
    return $descriptions[$fieldName];
  }
 
  public function getSchemaFieldType(TypeResolverInterface $typeResolver, string $fieldName): ?string
  {
    $types = [
      'username' => SchemaDefinition::TYPE_STRING,
      'email' => SchemaDefinition::TYPE_EMAIL,
      'url' => SchemaDefinition::TYPE_URL,
    ];
    return $types[$fieldName];
  }
 
  public function resolveValue(TypeResolverInterface $typeResolver, object $user, string $fieldName, array $fieldArgs = [])
  {
    switch ($fieldName) {
      case 'username':
        return $this->usersAPI->getUserLogin($user);
 
      case 'email':
        return $this->usersAPI->getUserEmail($user);
 
      case 'url':
        return $this->usersAPI->getUserURL($user);
    }
 
    return null;
  }
}

私の解決策はWPGraphQLのものよりエレガントだと思います。ただし、それは好みの問題です。Array-Driven Developmentを気にしない開発者も多く、実際にコンパクトなコードの塊ですべてのロジックを実装できるためそれを好む人もいます。

ラウンドの結果：引き分け。

引き分け

インターミッション

なんという夜でしょう、皆さん。

これまでの試合を分析する時間

試合の中間地点に達しましたので、トイレ休憩と、これまでの経緯についてのコメントをする良い機会です。

（その間、スポンサーからの広告を表示すべきでしょう。残念ながら、まだいません。あなたの会社がGato GraphQLの開発を支援し、このイベントのようなプライムメディアで露出を得たい場合は、メッセージを送ってください。）

スポンサーになって、あなたのブランドのプレミアム広告にアクセスしてください

なんという試合でしょう！WPGraphQLは最初から猛火のような勢いでした！試合の最初から絶好調で、Gato GraphQLに猛烈なパンチを次々と浴びせ、Gato GraphQLはかろうじて立っていられる状態でした。打撃に次ぐ打撃。Gato GraphQLの立場になりたくありませんでした。

認めなければなりませんが、最初の2ラウンドの後、すぐに試合が終わると思いました。いつノックダウンが来るかと待ち構えていました。タオルが投げられるのを見ることを予期していました。しかしGato GraphQLは持ちこたえました。それは認めなければなりません。なんという揺るぎない意志、まさに驚異的です！

そして変貌が起きました。3ラウンド目のどこかから、Gato GraphQLはどこからかエネルギーを得たように見え、自分を守るだけでなく、反撃のパンチを放ち始め、その多くがWPGraphQLの顔に届きました。WPGraphQLがよろめくのを見ました！現世界チャンピオンからこんなことを見たことはありませんでした。なんという真に驚異的な変貌を私たちは目撃したのでしょう！

そして、相手の自信を揺らがせた後、4ラウンドからGato GraphQLは一連の致命的な打撃を放つことを決意しました。それは驚異的でした！幸いにも、彼と対峙しているのは私たちの世界チャンピオンWPGraphQLであり、群衆の声援と共感に支えられて打撃に耐えることができました。なんというヒーローでしょう！他の誰でもすぐに倒れていましたが、彼は違いました。チャンピオンらしく打撃に耐えました。

しかし、チャンピオンとして続けられるのはどのくらいでしょう？まだ誰もノックダウンしておらず、まだ誰もタオルを投げていません。試合はいつでも決定的な転換を迎える可能性があります。2人のファイターは何を望んでいるかを知っており、全力と決意をもって再び相手に向かい、勝利するために戦い続けるでしょう。

なんという試合でしょう！

そして今、皆さん、2人の戦士がリングに戻ってきます。

選手たちがリングに戻ってくる

残りの試合へ！

重要な問題

GraphQLサーバーは、「必要なデータだけを取得する、それ以上でも以下でもない」という命題を満たすために、多くの考慮事項に注意を払う必要があります。

たとえば：

どれほど安全ですか？公開エンドポイントでプライベートデータを公開しないようにするにはどうすればよいですか？
どれほど高性能ですか？同じクエリを繰り返し送信する際のサーバー負荷をどのように削減し、できるだけ速くできますか？
どれほどシンプルですか？CMSが提供する機能を活用するために、WordPressとどれほどうまく統合されていますか？

そして多くの質問があります。これは私が選んだ小さなサンプルであり、次の3ラウンドで扱います。

ラウンド7: Persisted queries

Persisted queriesはGraphQLとRESTの両方の長所を組み合わせています：GraphQLを使用して作成されるため、データのアンダー/オーバーフェッチが発生しませんが、独自のURLを持つエンドポイントとしてサーバーに公開されます。

Persisted queriesには以下の利点があります：

✅ 安全です：単一のエンドポイントを通じてあらゆるデータへのアクセスを提供する代わりに、公開するデータを事前に定義できます。

✅ 速いです：独自のURLでアクセスされるため、標準のHTTPキャッシングを使用して、クライアントとバックエンド間のすべてのレイヤー（サーバー、CDN、ブラウザ）でキャッシュできます。

WPGraphQLはこれらの2つの拡張機能を通じてpersisted queriesをサポートしています：

さらに、Jason Bahl（WPGraphQLの作成者）は最近、近い将来WPGraphQLにpersisted queriesのサポートを追加すると発表しました。

すでに2つの拡張機能があるのに、何を考えているのか気になります。それらとどう違うのでしょうか？おそらく、サードパーティに依存せずにプラグイン全体のセキュリティ対策を強化するために、プラグインのコアの一部にしたいのかもしれません。

あるいは、Gato GraphQLの実装を見て、純粋なコードの代わりにビジュアルエディターで操作する同様のエクスペリエンスを提供したいのかもしれません？

それがGato GraphQLにつながります。Persisted queriesを提供するだけでなく、それを提供の中心的な部分にするよう努力しました：

✅ プラグインは単一のエンドポイントの無効化を可能にし、ユーザーはpersisted queriesのみを通じてデータを公開するよう推奨されます。

（対照的に、WPGraphQLはデフォルトでイントロスペクションのみを無効化し、実際のエンドポイントは無効化しません。言い換えれば、攻撃者は依然としてプライベートデータにアクセスできる可能性があります；プライベートデータが何かを事前に知ることができないだけで、タスクが難しくなっているだけです。）

✅ WordPressエディターと深く統合されているため、persisted queryを作成することはブログ投稿を作成することと同じ労力で可能であり、プログラマーだけでなく誰でもできます。

✅ Persisted queriesは静的ではありません：GraphQL変数を使用でき、その値はエンドポイントを実行する際のURLパラメーターを通じて提供できます。

私のプラグインでpersisted queryを作成して実行するエクスペリエンスをご確認ください：

ラウンドの勝者：Gato GraphQL。

ラウンド8: キャッシュ

GraphQLには大きな問題点があります：簡単にキャッシュできません。理由は、単一のエンドポイントにPOST操作を送信することに依存しているためです。単一のエンドポイントが異なる結果を生成し、クエリがURLパラメーターではなくリクエストのボディで送信されるため、単一のエンドポイントをキャッシュすることができません。

多くのGraphQLサーバーが提供する標準的な解決策は、キャッシングをクライアントに移し、エンドポイントのURLの代わりにオブジェクトのIDをキャッシュされるエンティティの識別子として使用することです。この機能を提供する最も人気のあるライブラリはApolloクライアントです。

WPGraphQLのキャッシングに使用可能なすべてのオプションについて、WPGraphQLリポジトリでの議論があります。興味深いことに、そのほとんどは外部ツール（Apolloクライアントや WordPress Object Cacheなど）であり、アプリケーションに追加のレイヤーを追加することを意味し、複雑さを増し、また速度を遅くする可能性があります。

（これらの理由は、WPGraphQLにpersisted queriesをネイティブに実装する決定の背後にある一部の理由でしょう。）

たとえば、Apolloクライアントはクライアントで実行されます。低スペックの携帯電話からウェブサイトにアクセスする場合、その余分なJavaScriptコードはアプリケーションのパフォーマンスに影響を与えます。

同様に、WordPressで作業する開発者はPHPには精通していても、JavaScriptにはそれほど精通していない場合があります。APIをキャッシュするには、JavaScriptレイヤーについても気にする必要があります。

Gato GraphQLはこのトピックについてよりスマートです。Persisted queriesを提供するため、クエリが独自のエンドポイントで実行されることを意味し、HTTPキャッシングを介してこれらのエンドポイントURLをキャッシュできます。

HTTPキャッシングヘッダーのmax-age値は、クエリ内のすべてのフィールドのすべてのmax-age値から自動的に計算され、この情報はフィールドごとにWordPressエディターを使用して設定されます。

その結果、APIは複数のレイヤー（クライアント、CDN、サーバー）でキャッシュでき、別のレイヤーを追加することなくプラグイン内でネイティブに処理されます。

APIエンドポイントがキャッシュされる様子を示したビデオをご覧ください：

ラウンドの勝者：Gato GraphQL。

ラウンド9: Gutenbergとの統合

かつてGutenbergはWordPressの未来になると言われていました。もはやそうではありません：GutenbergはいまやWordPressの現在（WordPressエディターと呼ぶことができます）であり、Full Site Editingが新たな未来となっています。

言うまでもなく、APIはWordPressエディターと良い統合が必要です。これはブロックのデータを取得・投稿するためだけでなく、WordPressエディター自体の機能を強化するためにも必要です。

たとえば、GraphQLサブスクリプションがサーバーからクライアントにリアルタイムでデータをプッシュできるため、協調編集や通知機能を強化するのに適しています。

WPGraphQLはWPGraphQL Gutenberg拡張機能を介してブロックデータをクエリできます。この拡張機能は各ブロックをマッピングする新しい型を作成するため、CoreParagraphBlock、CoreQuoteBlockなどが生まれます。

Gato GraphQLはもうすぐブロックデータをクエリできるようになります（作業中）。ただし、ブロックごとに新しい型を作成する代わりに、すべてのブロックを表す単一のBlock型を持ち、名前に基づいてあるブロックの特定のメタデータを抽出できます。

たとえば、段落ブロック内のコンテンツを翻訳する方法を確認してください（Google Translate APIに接続する@strTranslateディレクティブを使用）：

query TranslateStringsInBlocks {
  post(by: { id: 1657 }) {
    title
    paragraphBlocks: blockDataItems(
      filterBy: { include: "core/paragraph" }
    )
    translatedParagraphBlocks: blockDataItems(
      filterBy: { include: "core/paragraph" }
    )
      @underJSONObjectProperty(by: { path: "attributes.content" })
        @underEachArrayItem
          @strTranslate(from: "en", to: "fr")
  }
}

ラウンドの結果：引き分け。

スコープの拡大

「私には夢がある。」

Gutenbergブロックは、WordPressでコンテンツを作成するための単一のインターフェースを提供するように設計されており、CMSのコード開発とユーザーに必要な学習を大幅に簡略化しています。

コンテンツの作成のために導入されましたが、ブロックはCMSの他のすべての領域（ウィジェット、メニュー、そして近日Full Site Editingによるテーマ）を着実に引き継いでいます。そして将来的には、多言語機能や協調編集（ブロックを考えるときに考えもしない機能）もサポートするようになるでしょう。

GraphQLについても同じ観点で考えることができます：データと対話するための単一のインターフェースとして。つまり、データの取得と投稿だけでなく、編集を含むデータを含むあらゆる対話が対象です。

WordPressには、真にウェブのOSになる絶好の機会があります：Gutenbergで動くシステムで、ユーザーがあらゆる種類のコンテンツ（テキスト、画像、動画、音声など）を入力し、独自のツールやクラウドベースのサービスを介して処理し、WordPressサイトまたは他の場所である最終的な目的地に公開できます。

しかし、この強力な夢の背後には、私たちが置く要件を何でも届けることができる、真に強力なAPIが必要です。GraphQLに基づきながらも、その制限を超越するように設計されたAPIです。

ラウンド10: カスタムディレクティブのサポート

ラウンド10の開始

WPGraphQLは単一のディレクティブを搭載していません。サポートしていないと言っているのではなく（エンジンのwebonyx/graphql-phpはサポートしています）、カスタムディレクティブの実装を提供していないということです。

「それで？」と思うかもしれません。「ディレクティブが何のために必要なの？誰かがクエリの結果を変更する必要があれば、自分のクライアントで行えばいい！」

ディレクティブが必要な理由は？

これは意見の問題であり、正しいや間違いはありません。しかし、少し話させてください：ディレクティブは非常に便利な機能であり、GraphQLをRESTと区別するのに役立ちます。使用していない場合、APIを最大限に活用していない可能性が高いです。

ディレクティブは仕様によって規制されていないため、GraphQLサーバーは任意の方法で実装でき、必要なだけ強力にできます。だからこそ、@streamと@deferなどのように、GraphQLの多くの新機能は最初にディレクティブとして導入されます。

Gato GraphQLはディレクティブを敬意をもって扱います。一度だけ実行され、適用されるすべてのフィールドについてすべてのエンティティのデータで実行されます（これが@strTranslateディレクティブがGoogle Translate APIから非常に素早く結果を取得できる理由です）。また、GraphQLエンジン自体がディレクティブパイプラインに基づいています。

しかし、このすべての力をユーザーに利用可能にすることを恐れているのでしょうか？それは正当な懸念です。しかし、単一のエンドポイントへのアクセスを削除して、persisted queriesのみを通じてデータへのアクセスを提供することができます。その場合、ディレクティブへのアクセス権を持つのは（サイトの管理者である）あなただけです。

つまり、あなたがメリットを享受するか、何も起きないかのどちらかです。

ディレクティブが好きなら、Gato GraphQLが大好きになるでしょう！❤️

しかし一方で、好きでなければ、何も起きません。

ラウンドの勝者：Gato GraphQL。

（「くだらないディレクティブなんて不要だ」と思うなら、怒らないでください……私はただ自分の仕事をしているだけです。）

ラウンド11: RESTのサポート

「えっ？REST？何のREST？ここでGraphQLの話をしているんじゃないの？なぜRESTの話をするの？なぜ私の人生を複雑にしたいの？」

これ以上はできません

確かに、最初はこのトピックは場違いに思えます。しかし、非常にシンプルな理由でこの比較に追加しました：Matt MullenweはWordPressコアへの潜在的な組み込みのためにGraphQLを検討していると述べており、貢献者が心配することは2つのコードベースを維持しなければならないことです。

これが明らかな質問につながります：GraphQLサーバーはRESTも処理できますか？

答えはWPGraphQLについては「部分的にはい」、Gato GraphQLについては「完全にはい」です。

WPGraphQLについて。RESTエンドポイントを定義することが可能で、解決される際に、GraphQLエンジンへの内部呼び出しとして、または同じウェブサーバーに対して実行される外部POST操作として、必要なフィールドを含むGraphQLクエリを実行します。

しかし、それはWP REST APIを満たすには不十分です。なぜなら、JSONスキーマも持っており、それなしではやっていけないからです。

Gato GraphQLについて。幸運だったことを認めなければなりません。基盤エンジン（PoPと呼ばれるサーバーサイドコンポーネントモデル）の作業は2013年頃に始まりました。つまり、GraphQLというものを知るよりも数年前であり、このプロジェクトは独自のアイデアをもって進化しました（この私のビンテージ記事に文書化しています）。

そして、CMS非依存のGraphQLサーバー（Gato GraphQLが立脚するもの）のコーディングを約1.5年前に始めたとき、PoP向けに開発したアイデアとGraphQLが確立した基盤を組み合わせ、GraphQL仕様を完全にサポートしながら、それに異なる機能セットを追加できるシステムを作成しました。

この点で、PoPが使用するスキーマはAPI非依存であり、GraphQLのスキーマのスーパーセットです。PoPスキーマは/api/graphql/?query=fullSchemaにあります。

そして、GraphQLサーバーレイヤーはGraphQL仕様に従ってPoPスキーマをフォーマットし、GraphQLスキーマを生成します。同様に、WP REST APIが必要とするJSONスキーマを生成できます。

このJSONスキーマの生成はまだ完了していませんが、実現可能です。

現在すでに完了していることは、クエリのレスポンスを複数のフォーマットで生成することです。たとえば、このGraphQLクエリ：

{
  posts {
    id
    title
    date
    author {
      name
    }
  }
}

このRESTエンドポイントを介しても解決できます：/posts/api/rest/?query=id|title|date|author.name。

そこで止まる必要はありません。XMLなどの別のフォーマットで結果を生成する必要がありますか？問題ありません：/api/?query=posts.id|title|date|author.name&datastructure=xml。

（これはスキーマに基づくWordPressの新しいインポート/エクスポートツールの提案の実装を助けることができるでしょう。これはまた、私が以前に言ったことをより明確にします：単一のインターフェースがCMS内のすべてのデータ対話だけでなく、CMSと外部APIとの対話も駆動できます。）

ラウンドの勝者：Gato GraphQL。

ラウンド12: 新機能のサポート

GraphQL仕様は最終的なものですか？答えはいいえです：仕様は常に進化しています。現時点では100のオープンイシューがあり、その多くは将来のある時点で正式化される提案を含んでいます。

さて、それらの100のイシューの中には、今日メリットを享受できる新機能が確かにあるでしょう？もしそうなら、なぜ待つのでしょうか？

それがまさに私の考え方です。

永遠には待てない

「しかし、GraphQL仕様にないものをGraphQLサーバーに追加すべきではありません、ユーザーが混乱します！」

良い指摘です。しかし、新機能をオプトインとしてのみ利用可能にすれば、ユーザーは必然的にそれを認識し、問題や誤解は生じません。

これも私の考え方です。ただし、これは意見の問題ですので、すべてのGraphQLサーバーが使用している機能だけを使用したいのであれば、それで構いません。

WPGraphQLはそのように動作していると思います。少なくとも、仕様で承認されていることを超えた単一の機能は見たことがありません。

Gato GraphQLについては、仕様のイシューリストを定期的にスキャンし、私のサーバーであまり労力をかけずに満たせるクールな機能を見つけたら実装します。（実際、これは私の趣味の一つです。）

これらは私がこれまでに実装した「前向き」な機能です：

✅ 複数クエリの実行
✅ スキーマの名前空間
✅ ネストされたミューテーション
✅ コンポーザブルディレクティブ
✅ プロアクティブフィードバック
✅ フィールドおよびディレクティブベースのバージョニング

そして既に追加を計画しています：

✳️ Subscriptions（これは既に仕様の一部です）
✳️ @streamと@deferディレクティブ
✳️ フラットチェーン構文

ラウンドの勝者：Gato GraphQL。

判決！

皆さん。

判決の時

なんという忘れられない夜だったでしょう！なんという試合を経験したでしょう！2人のヘビー級が夢のために全力を尽くしました。

両者が追いかけている夢ですが、手にできるのは一人だけです。

そして今、その人が誰かを知ることになります。今、真実の時です！

「WordPressのGraphQL」世界チャンピオンは誰になるのでしょうか？

広く称賛され、大衆に愛され、大きな媒体に取り上げられた現チャンピオンのWPGraphQLでしょうか？

それとも、型破りで、許しを求めず踏み込み、招かれざる客として現れた挑戦者Gato GraphQLでしょうか？

選手たちが判決を待つ

審判の判決を待っています。なんという緊張！ああ神様、この瞬間に私の心が耐えられるようにしてください！

🥁 そして 🥁 勝者は 🥁 いいいいいいいいいいいい 🥁 ...

引き分けです！

2人のファイター、2人のヘビー級、引き分けです！

選手たちが抱き合う

なんという素晴らしい瞬間でしょう！2人の選手が抱き合い、私たちが大きな家族のようなWordPressコミュニティの中でみんな友達であることを示しています。

では、引き分けの理由は何でしょうか？審判が説明します：

👑 WPGraphQLはより人気があり、その使用はより広まっています。

👑 Gato GraphQLはより優れたアーキテクチャを持っており、長期的にWordPressをよりよく支えられる可能性があります。

皆さん、審判からの判決をいただきました！

そして私たちのトロフィーには2つのグローブがあります：各選手に一つずつ。

「WordPressのGraphQL」トロフィー

しかし、あなたの判決は何でしょうか？

ヘッドレスのニーズのためにWPGraphQLを無条件に使い続けますか？

それともGato GraphQLが求めているチャンスを与えて、プラグインをダウンロードして試してみますか？

皆さん。今夜はここまでです。

試合を楽しんでいただけたことを心から願っています。

そして2人のチャンピオンの新たな対決がまたすぐに実現することを願いましょう。

おやすみなさい。

2024年05月01日更新: Gato GraphQL vs WPGraphQL の比較でさらに詳しく学びましょう。

🥊 Gato GraphQL vs WPGraphQL: 対決！

人気度

ラウンド1: 誰が使っているか、どれほど完成しているか

ラウンド2: 拡張機能の利用可能性

ラウンド3: 対象ユーザー

コードスタイルと標準

ラウンド4: PHPの要件

ラウンド5: コーディング手法

ラウンド6: スキーマの拡張

インターミッション

重要な問題

ラウンド7: Persisted queries

ラウンド8: キャッシュ

ラウンド9: Gutenbergとの統合

スコープの拡大

ラウンド10: カスタムディレクティブのサポート

ラウンド11: RESTのサポート

ラウンド12: 新機能のサポート

判決！

ニュースレターを購読する