6年使ってGraphQLをやめた理由

• 2018年から6年間使い続け、真のGraphQL熱狂的ファンだったが、今は懐疑的になっている
• なぜ今はGraphQLを勧めないのか、そして何がより良い代替案だと考えているのかを説明したい

攻撃面

• GraphQLはクエリ言語を公開することで、攻撃面を広げるリスクがある。
• 認可に関する問題は特に重要。
  • すべてのフィールドについて適切な認可チェックが必要。
  • REST APIでは、エンドポイントごとに認可を検査するほうがシンプル。

認可

• すべてのフィールドについてユーザー権限を確認する必要がある。
• REST APIでは、エンドポイントごとに認可を検査するほうがシンプル。

レート制限

• GraphQLクエリにはサイズ制限がなく、サーバーに大きな負荷をかける可能性がある。
• クエリの複雑さを見積もり、一定の複雑さを超えるクエリを制限する方法がある。
• REST APIでは、リクエスト数を制限するほうがシンプル。

クエリ解析

• 不正なクエリ文字列がサーバーのメモリを過剰に消費する可能性がある。
• 最大エラー数を設定して解析を中断する方法がある。

パフォーマンス

データフェッチとN+1問題

• フィールドリゾルバが外部データソースを何度も呼び出すことがある。
• Dataloaderパターンを使ってこの問題を解決できる。
• RESTでは、コントローラでN+1問題を解決するほうがシンプル。

認可とN+1問題

• 認可コードがN+1問題を引き起こすことがある。
• RESTではこの問題は発生しない。

結合

• GraphQLのコードベースでは、ビジネスロジックがトランスポート層に強く結合している。
• 統合テストが必要で、デバッグも難しい。

複雑性

• GraphQLのセキュリティやパフォーマンスの問題に対処するためのさまざまな方法が、コードベースの複雑性を増大させる。
• RESTの解決策は一般的によりシンプル。

代替案

• OpenAPI 3.0+を使うJSON REST APIを推奨。
• 静的型付け言語で書かれたクライアントがある場合、OpenAPIのほうがより良い選択肢になりうる。
• OpenAPIは型安全なクライアントコードを自動生成できる。

GN⁺の意見

• GraphQLは強力だが、セキュリティやパフォーマンスの問題を解決するには多くの努力が必要。
• REST APIは比較的シンプルで、多くの場合により適している可能性がある。
• OpenAPIは型安全性と自動化されたツールを提供し、開発生産性を高められる。
• GraphQLを導入する際は、セキュリティとパフォーマンスの問題を十分に考慮する必要がある。
• RESTとGraphQLの長所と短所を比較し、プロジェクトに合った技術を選ぶことが重要。

[savvykang]

6年ぶりにGraphQLをやめた理由

[yangeok]

RPC大流行の時代がやってくる

[ahwjdekf]

そりゃそうだよな……。何か fancy なものが出てきたからって、むやみに飛びついて持ち上げちゃいけないってことだ。次は ORM の番だな。お前もそう遠くない……

[rockmkd]

ORMは登場してからもう20年以上になりますが…

[cometkim]

2018年ならPQはそれほど新しくもなかったはずですし（実際、GraphQLが最初に発表されたときから推奨されていた）、6年間試していなかったというのは驚きですね…

[surfindia]

上で述べたあらゆる理由から、GraphQL をすべて手作業で実装するのは、複雑さや安定性の面で難しいです。hasura や postgraphile のようなレイヤーを DB の上に置き、必要に応じて GraphQL でも REST でもこのレイヤーに追加していく形で開発するのがよさそうです。

[GN⁺]

Hacker Newsの意見

• GraphQLを導入した後、多くの問題を経験した。権限管理とパフォーマンスの問題のため、もう使いたくない。フロントエンドだけで使うなら良いかもしれないが、バックエンドとの統合は複雑だ。
• まずRESTを学び、その後gRPCを使ってみると、型安全なAPIが魅力的だった。GraphQLにはそれほど多くの利点はなく、データベースのように動作するときにだけ有用だ。
• 2つのGraphQLプロジェクトで働いたが、最初は小さく始まったものの、時間が経つにつれて複雑になった。デバッグが難しく、パフォーマンスの問題が発生した。RESTとRPCの方がよりシンプルで管理しやすい。
• Hasuraの創業者として、GraphQL利用の進化を見てきた。GraphQLはデータレイヤーがなければ構築が非常に難しい。RESTの上にGraphQLを使うのは非効率だ。GraphQLの主なユースケースは、複数のデータ利用者がいる場合だ。
• フロントエンドエンジニアたちはクエリを中央ライブラリに保存して再利用しているが、これはGraphQLをRESTのように使っているのと同じだ。
• OpenAPI、GraphQL、JSON/HTTP、gRPCを使ってきた経験から言うと、GraphQLクエリを制限することでパフォーマンスとセキュリティの問題を緩和できる。Buf Connectがほとんどのプロジェクトにとって最適な妥協点だ。
• FacebookでGraphQLを使った経験では、多くの人はGraphQLが解決しようとしている問題を抱えていない。Facebookはバージョニングと複雑なオブジェクトモデルを扱うためにGraphQLを使っている。
• FacebookでGraphQLがうまく機能する理由は、すべてのユーザーがログインしており、セキュリティがすべてのフィールドに組み込まれているからだ。SPAとログイン要件がある場合、GraphQLは有用かもしれない。
• GraphQLを使ってみると最初は良かったが、結局は多くの追加作業と重複が必要だった。JSON-RPC型のエンドポイントから始めて、必要な機能を追加していく方がよかった。
• 小さなプロジェクトでGraphQLを使ってみたところ、ほぼすべての点で良かった。Apollo Clientとgraphql-codegenを使ってVue 3向けの型と関数を生成した。いくつか問題はあったが、型レベルで多くのエラーを防げた。