今までGraphQLを何回か採用してきましたが、結局のところ使わないほうが良いと感じています。本記事ではその理由を解説します。

オーバースペック

多くのプロジェクトでは、REST APIやシンプルなエンドポイントで十分対応可能です。 GraphQLの複雑さは、開発者にとって負担となり、学習コストも高くなります。

JSONしか返せない

GraphQLは柔軟性が高いように見えますが、実際にはJSON形式でしかデータを返せません。 ファイルをダウンロードする機能を実装したい場合、次のいづれかから選択することになります。

1. JSONを返してフロントエンドでCSVを生成する
2. サーバーサイドでCSVを生成してファイルをS3などのオブジェクトストレージに保存し、そのURLを返す
3. ファイルを返す専用のマイクロサービスを立てる

1の場合JSONを返すのでレスポンスサイズが大きくなりがちです。 2の場合、ファイルをダウンロードするためだけにオブジェクトストレージのセットアップが必要になります。 また、ファイルのクリーンアップ処理についても考えなければなりません。 3はファイルのダウンロードだけにマイクロサービスを立てるのは過剰設計です。

GraphQLを使う場合は、これらの課題があることを前提に設計を考える必要があります。

(ほぼ)コード生成が必須

GraphQLを使う場合、型安全性を確保するためにコード生成がほぼ必須となります。 GraphQLに限らず、コード生成する場合は生成されたコードの管理やビルドプロセスへの統合が必要になります。 これにより、開発プロセスが複雑化します。

多くの場合、ビルドプロセスは管理されず生成のヌケモレが発生しがちです。

クライアントが複数になることはほぼない

GraphQLはクライアントが複数存在する場合に真価を発揮します。 しかし、実際のプロジェクトではクライアントが1つだけであることがほとんどです。 そのため、GraphQLの利点を活かすことができず、逆に複雑さだけが増してしまいます。

まとめ

本当にGraphQL必要ですか？ ただ、「便利そうだから」「流行っているから」「(なんとなく)イケてるから」などの理由で採用すると後で痛い目にあいます。 ほとんどの場合、REST APIやシンプルなエンドポイントで十分対応可能です。