APIは普段何を使っていますか。
私は新しいアプリケーションを開発するに当たって「REST API」と「GraphQL」どちらを使うべきか比較し、GraphQLを使うことにしました。
なお、筆者は今まではRESTで採用しておりGraphQLは未経験です。
今回は私がなぜGraphQLを選んだのか、どういったところが魅力的だったのかなどREST APIと比較をして書いていきたいと思います。
GraphQLって何？
まずはGraphQLとは何なのか、ご存知の方も多いと思いますが簡単に説明します。
GraphQLは、APIのためのクエリ言語であり、既存のデータを使ってクエリを実行するためのランタイムです。GraphQLは、API内のデータについて完全で理解しやすい記述を提供し、クライアントに必要なものだけを要求する力を与え、時間の経過とともにAPIを進化させることを容易にし、強力な開発者ツールを可能にします。
引用: GraphQL公式サイト
クエリとは直訳だと、「問い合わせ（る）」、「訪ねる」などの意味です。
今回はAPIのクエリ言語ですので簡単に言うと、クライアントアプリケーションが必要なデータをAPIから取り寄せる時に使われる言語ということですね。
GraphQLのメリットとデメリット
続いて参考にしたGraphQLのメリット・デメリットをそれぞれ紹介していきます。
[メリット]
-
少ないリクエストで複数のリソースにアクセス可能
REST APIでは特定のエンドポイントを呼び出すことができませんでした。
しかし、GraphQLでは1つのエンドポイントで複数のデータを取得できるため、リクエストが無駄になることなく、パフォーマンスの低下を招きづらく、サーバー側に負担をかけずにフェッチが行えます。 -
最小限のデータのみを取得
REST APIではアクセスしたエンドポイントに含まれる全ての情報を取ってきてしまうため、オーバーフェッチングになってしまっていた。
対してGraphQLは欲しい情報を細かく選んで最小限で取ってくることができます。 -
型指定でデータが明確になる
GraphQLは型指定ができるのでどういったデータを扱っているのか見た目でも分かりやすくなる。
型指定は間違いがあった際はエラーを出してくれるのでバグがすぐに見つけることができるため堅牢性に繋がります。
[デメリット]
-
学習コストがかかる
GraphQLは、2015年に登場した比較的新しい規格のため、情報量が少ないです。
独学の場合、少ない情報の中で勉強をしなければならないので、マスターするまでに一定の時間がかかることもあります。 -
RESTよりもキャッシュが複雑になりやすい
RESTの場合、URLベースでキャッシュを生成するため、比較的容易に扱うことができます。
一方、GraphQLのキャッシュはURLを生成せず、レスポンス内容も異なるため、複雑です。
そのため、CDNによるオフロードの実現が難しかったり、クライアントサイドへ悪影響を及ぼしたりする可能性があります。
REST APIとGraphQL APIの比較
その他代表的な特徴についても比較していきます。
| REST API | GraphQL API | |
|---|---|---|
| 通信プロトコル | HTTP | HTTP |
| ペイロードの形式 | (主に)JSON | (主に)JSON |
| エンドポイント | 複数 | 1つ |
| 型付け | 弱い | 強い |
| データ操作の種類 | GET/POST/PUT/DELETE | Query/Mutation |
| データ取得の柔軟性 | 低い | 高い |
| クライアントからサーバへのリクエストの数 | クライアントの要望に応じて複数回のリクエストが送られることがしばしばある。 | 必要なデータを過不足なく指定することで、1回のリクエストで済ませる。 |
データが複雑に関係し合うようなケースでは、RESTよりもGraphQLのほうが適しています。
クライアントは柔軟なクエリを投げることができ、サーバはクライアントの複雑な要求を気にすることなくAPIを実装できます。
私が選んだ理由
簡単ではありますが、今回私は以上の様な情報をもとに検討を行いました。
ここまで見ていただいて分かる通り、GraphQLは多くのメリットがありますが今回私がGraphQLを選んだ理由は以下の通りです。
- 無駄が少なくスッキリと記述できる
これは好みの問題ですが、私は無駄は出来るだけ省きたいタイプなので、エンドポイントが1つだったりオーバーフェッチングが避けれると言うのは、非常に魅力的に感じました。
また型付けが強いのも今回TypeScriptを使って開発を行うため、同様に分かりやすい記述へと繋げていけると感じました。
- TypeScriptでSchemaが作れる
上では紹介がありませんでしたが、GraphQLはSchemaを作る方法が2つあります。
コードファーストアプローチと呼ばれるType ScriptファイルからGraphQL Schemaを作る方法と、
スキーマファーストアプローチと呼ばれるGraphQL SchemaからをType Scriptファイル作る方法です。
今回私は開発でNext.jsとNestJSを使う想定なのでType Scriptはとても相性が良いです。
- 作成するアプリケーションが比較的難易度が低い
今回私が作成するアプリケーションは個人開発で作成する、簡単な口コミアプリを想定しているため難易度はそこまで高くありません。
デメリットにあるCDNによるオフロードも想定はしていません。
複雑な開発を想定している場合は世に出ているドキュメントが少ないため、問題解決で時間を要する可能性はあるため注意が必要だと思います。
- 現在学習に割く時間がある
個人的に現在学習に割く時間があるため、学習コストがかかるデメリットは時間でカバーし、
新しい技術にチャレンジしたい考えたからです。
また、日本語ではまだドキュメントが少ない技術ですが、英語では比較的多くのドキュメントが出されている様に感じました。
また、Next.jsとNestJSのそれぞれの公式ドキュメントにも、GraphQLのページが用意されており、導入は比較的簡単に行えそうです。
まとめ
以上がなぜ私がGraphQLを選んだかについてでした。
実際GraphQLでできることは究極的にいえばRESTful APIと非常に大きな差は無いと思います。
それぞれの開発環境や状況に合わせて選んでもらうのが良いかと思います。
少しでも同じ様にAPIの選択で悩んでいる人の参考になれば嬉しいです。