知識のリンク集

技術系アウトプット

GraphQL & Apolloを導入してよかったこと

現在開発しているモバイルアプリは既に5年ものとなりました。
APIに関してはRESTを採用しています。

5年も経つと機能も増え、それに伴いAPIやデータ構造も複雑になってきてチーム全体として仕様の把握に課題を感じるようになってきました。

そんな折、新しい機能を作る際にGraphQLを採用し、 クライアント側にはApolloを導入しました。

これにより個人的に嬉しかったことが下記の4つです。

  • スキーマ駆動開発で作業がブロックしない
  • 画面単位で情報設計を考えることができる
  • コードレビューしやすい
  • 脱Reduxによりテスト箇所が減った
スキーマ駆動開発で作業がブロックしない

先にスキーマを定義することで、サーバー側の実装を待たずしてフロントに着手できました。

スキーマ定義はスプリントプランニングの時点で行い、画面単位で「この画面にはどんなデータが必要か」という情報設計をチームで話し合いました。

現段階ではクエリは画面単位で用意しています。

画面単位で情報設計を考えることができる

クエリを画面単位で用意することで情報設計をシンプルにできました。

またクエリの命名(=オペレーションネーム)はAPIのレスポンスに揃えてフロントで自由に変えられるのでクエリのリストを作成する際もフロントの把握しやすいように管理できます。

余談: クエリーとミューテーションの型の命名規約

クエリ: 名詞(どのデータを取得するか)
ミューテーション:動詞+名詞(どのデータをどう変更するか)

これに対し、フロント側でさらに同じクエリでも使用シーンを説明できるようなオペレーションネームをつけることでデータオブジェクトとその扱い方を分離し、後者に関してフロントで管理しやすくなりました。

コードレビューしやすい

オペレーションネームと実際に取得できるデータがコードで確認できるためコードレビュー時にデータに関しても把握・レビューすることができます。

脱Reduxによりテスト箇所が減った

ApolloのおかげでReduxにデータを保持する必要がないため、Reduxの処理をまるっと書かなくてよくなりました。

Reduxに関するコードがない分テスト箇所も減りますし、データの取得も欲しい形でリクエストできるためフロントでは受け取ったデータをそのまま使うだけですみました。

今までは複雑化したREST APIの都合上、フロントでデータ整形が必要なケースもあり、その分受け取ったデータをそのまま使うだけとはいかずロジックが分散することがあったのでこれは本当に解消できて嬉しい部分でした。