かなり前になりますが本ブログで、GraphQLについて取り上げました。
https://toaruit.hatenablog.com/entry/2017/08/10/205836
それから数年経って、GraphQLという選択も珍しくなくなってきたこともあり、今回はメリット・デメリットなどをまとめてみます。
あらためて概要からですが、GraphQLはAPIとしてクエリを標準の機能として実装されていて、またそのレスポンスのスキーマも定義されています。ので、発行元は必要なデータを取捨選択して取得できます。
【「GraphQL」徹底入門 ─ RESTとの比較、API・フロント双方の実装から学ぶ】
https://employment.en-japan.com/engineerhub/entry/2018/12/26/103000
まず、メリットからですが、下記の記事にざっとまとめられています。RESTでは複数回リクエストを投げる必要があるケースがあるとしたら、一度のリクエストでとってこれる可能性があります。また、スキーマの定義をする必要があるので、どういったデータがあるかを見渡しやすいという点も挙げられます。
【GraphQLはRESTの置き換えではない】
https://note.com/konpyu/n/nc4fd122644a1
スキーマがあるメリットについて、下記の記事にまとめられています。あらかじめ型を定義しておくことは、コミュニケーションコストの削減にもつながるとのこと。
【RESTを採用して気づいた「GraphQLって結局何が良いの？」について】
https://www.utakata.work/entry/2019/12/02/000000
逆に、デメリットとして挙げられているものを紹介します。
デメリットというほどのものではないですが、下記の記事で挙げられてるのはフィールドをいちいち指定しなければいけないことで煩雑さが生まれる点。これはメリットの裏返しですね。あとはクエリの結果がエラーなのに、HTTPステータスコードが200で返ってきてしまうという点が挙げられてます。
【GraphQLは何に向いているか】
https://k0kubun.hatenablog.com/entry/graphql
あと下記の記事で挙げられているのは、実装工数が高くなる可能性がある点です。フロント側でクエリを実装するのに加えて、サーバ側でもそのクエリからSQLを組み立てる実装を行うコストが発生します。もちろんこれは現状のデメリットであって、将来的に自動で組み立ててくれるミドルウェア的なのが広まれば解消する可能性はあります。
【GraphQLは90%のウェブサービス開発者にはまだ時期尚早ではないか】
https://qiita.com/shibukawa/items/a913cb4912d32af37bc5
で、まとめるとGraphQLは全てRESTに置き換えられるものではなく、導入に際してコスト等鑑みて有効性があるか検討する必要があると、個人的に感じます。特に現状のRESTで例えばクエリを不用意に数回投げていたり、APIのインターフェースが把握できないと言った課題がある場合は、実装コストを多少払っても導入する価値はあるかなとは思います。
