2019年9月追記しました!
最近GraphQLを扱うことが多かったのでその印象をまとめておこうかと思います。 現在、2018年10月の印象なのでここで上げたデメリットは今後解消されるかもしれないので悪しからず。
メリット
エンドポイントをいちいち設定しないで済む
扱ってみて最大のメリットだと感じたのが、RESTと違いエンドポイントが一つしか無い点です。そんなもんかと思うかもしれませんがGraphQLを使ってみていかにエンドポイントを新しく作るのが面倒だったのか痛感しました。
通常エンドポイントを作るには以下の作業が必要です。
- URL設計
- エンドポイントの共有
- クライアント側の修正
- サーバ側の修正
これらの点をGraphQLならサーバ側が新しくスキーマを定義して上げれば済むので、後は勝手にクライアント側が利用するだけとなります。
GraphiQLサーバが便利
だいたいどの言語のGraphQLを扱う仕組みでもGraphiQLサーバが実装されています。GraphiQLサーバではクエリをチェック出来るのでドキュメント代わりになれます。なのでAPI仕様書をいちいち作らなくても非常に便利で後はクライアント側がそこを参照さえすればいいので、タスクが疎結合になります。
実装とドキュメントが一致している
昔からあるアプリケーションの場合、ドキュメントで定義されている内容と実際のレスポンスが異なっているというのはあるあるだと思います。しかし上記のGraphiQLサーバは実装からドキュメントを定義されるため実装とドキュメントが異なることはありません。そのため、保守が非常に楽です。
型が定義されている
RESTもちゃんとやれば別に問題ないのですが結構神経を使うのでそこはGraphQLだと事前に定義するので便利でした。
デメリット
Apollo Clientが枯れていない
GraphQLを扱うとするとだいたいみんなApolloにたどり着くのですが、正直まだ枯れていないです。というよりGraphQL自体が枯れていないのでベストプラクティスがまだ発見されていないというのが正確だと思います。私はiOSではApolloを使いましたが開発途上だなというは感じました(Swiftとのバージョンの組み合わせなど)。
また、JavaScriptではReactとReduxで併用しようとしましたがと共存させかたがよくわかなかったのでApolloは見送って以下のミニマムなライブラリを使用しました。問題は全然無かったです。
見送った別の理由で言うとApolloがapollo-link-state
という新しい概念を提唱しているのですが現段階では流石に運用事例がほとんど無かったので見送ったのも理由です。万が一今後伸びてくるのであればその時に乗り換えればいいかと判断しました。
情報が英語
日本語の情報は非常に少なくだいたいは入門レベルなのできっかけにはなるけど全てカバー出来るわけではありませんでした。そのため英語の公式ドキュメントに頼ることになります。ただ英語ドキュメントでも使い方は載っているけど、困った時にどういう風に解決したかという情報はネット上には少なかったです
向いているアプリケーション
GraphQLが特定のアプリケーションのみ向き不向きがあるというわけではありませんが、向いているアプリケーションというのはあります。
例えば、クライアント側の開発が活発なアプリケーションでは向いていると感じています。例えば、iOS, Androidアプリとの連携などは向いています。反対に社内向けのAPIを提供する時はさほどメリットがあるわけでもないなと感じています。
まとめ
GraphQLを導入した方がいいのどうなのという意見でいうには、新規開発ならぜひ採用してRESTを置き換えるなら無理して導入しなくていいんじゃねというのが感想です。教育コストが云々の話もありますが一人がちゃんと勉強して横展開すればそこまでコストもかからないというのが印象です。