はじめに
弊社のプロダクトでGraphQLを採用してから約2年が経ちました。モバイルアプリの新機能開発に関するAPIは全てGraphQLで実装しています。
私自身２年間の中でクライアント(iOSモバイルアプリ)、バックエンドの両方でGraphQLでの開発をしてきたので、その間に感じたGraphQLの良さをまとめます。
好きなところ
GraphQLスキーマの存在
RESTのAPI設計と比較して僕が1番好きなのが、GraphQLスキーマの存在です。REST APIの場合はAPIの仕様を別にドキュメンテーションする必要がある上に、クライアント側で使う際は型の不整合が起きないように気を使う必要があります。
一方でGraphQLの場合は、GraphQLスキーマの作成が開発システムに組み込まれており、その結果APIの仕様がスキーマに一元管理されます。そのため、クライアント側ではスキーマに基づいた型のチェックが行えます。また、GraphQLスキーマがあることで、APIの仕様を確認する際にはGraphiQLなどのツールを使うことで、リクエストの形式やレスポンスの形式を確認することができ、ドキュメンテーションの手間も省けます。
エコシステム(ライブラリ)の充実
弊社はバックエンドはRailsでライブラリはGraphQL Ruby、モバイルはiOS,Android共にApolloを利用しています。当たり前のようにGraphQLならライブラリが使えますが、REST APIの場合は自由度の高いスキーマ設計ができてしまうので、クライアントの種類や設計によってはライブラリの利用ができないこともあり得ます。
開発が活発なライブラリを利用できるのは、GraphQLのエコシステムが充実してるからこそだと思います。
直近のプロジェクトでも、ユーザーの状態によってクエリ不可にする機能を実現するためにGraphQL RubyのAuthorizationを利用することができました。
クエリの柔軟性
クライアント側で必要なデータをクエリできる柔軟性はとても魅力的だと思います。Fragment Collocationのように、コンポーネントごとに必要なデータを集めるような設計を選択することもできますし、データアクセス層を明確に分けるためにそれを避けることもできます。
Next.jsのServer ComponentsもCollocationの考え方を取り入れられることが１つの魅力のようです。ただ、それを実現するためにはREST APIの設計も今までよりも細かい粒度にする必要がありそうです。弊社のようにモバイルなど複数のクライアントを持つ場合は、フロントエンドのためだけにAPIを細かい粒度で実装するのはやりずらいかもなと感じました。
一方GraphQLは、モバイル、フロントエンドそれぞれでクエリを作ることができるので、クライアント側の作りたい設計に柔軟に対応できるのが魅力的だと思います。
まとめ
僕が好きなGraphQLの魅力をまとめました。クライアント、バックエンドともにすごく開発がしやすい技術だなと感じています。
来年は個人的にGraphQLを使ったサービスを作って、その過程でGraphQLの良さをもっと知りたいなと思っています。
Discussion