これはJapanTaxi AdventCalendar 11日目の記事です。
JapanTaxiアプリのリニューアル時に新たに取り入れたGraphQLについて、Androidアプリで実際使ってみてどうだったかを紹介したいと思います。
はじめに
AndroidアプリでGraphQLを使うためにApollo GraphQL Client for Androidを使いました。
Apolloはスキーマ定義ファイルとQueryやMutationを書いた.graphqlファイルからJavaクラスを自動生成してくれるライブラリです。
また、サーバーのスキーマ定義を取得するためにApollo CLIを使います。
Apolloを用いた開発の流れ
大まかには以下のような流れで開発しています。
- サーバーからスキーマ定義ファイルを取得する
- QueryやMutationを.graphqlファイルに書く
- ビルドする
- Apolloが必要なクラスを自動生成してくれる
- 生成されたクラスを用いてサーバーへアクセスする
Query、Mutationはどうやって書いてる？
.graphqlファイルに書くQueryやMutationはGraphiQLやGraphQL Playgroundを使ってスキーマ定義から生成されたドキュメントを参照しながら書いています。
その場でレスポンスを確認することができてとても便利です。
サーバーサイドのメンバーが環境を整えてくれていたので、簡単に試しながら作成することができました。
デバッグ方法
ApolloではHTTP通信にはOkHttpを使います。そのため実際のリクエストやレスポンスを確認したいときにはStethoを使って確認することができます。
そのためREST(Retrofit + OkHttp)とGraphQL(Apollo + OkHttp)とでAPIのログを１画面で確認しながらデバッグすることができます。
また、キャッシュ内容も同様にStethoで確認できます。
GraphQLを使ってみてよかったこと
複数のリソースを１回のリクエストで取得できちゃう
１番便利でクライアント視点で楽になることは複数リソースを１回のリクエストで取得できることです。
RESTだとリソースによりエンドポイントが別れていると思います。そのためクライアントはサーバーへ必要な情報を取得するために複数のリクエストを送る必要がありました。
JapanTaxiアプリでの例をあげるとトップ画面で表示する情報を取得する際に以下の情報を取得します。
– お知らせの未読数
– 配車中の注文
– お気に入りショートカット
RESTではお知らせ、注文、お気に入りと異なるリソースであるため３回リクエストを送るか、画面表示で必要な情報をまとめて返す専用APIをサーバーへお願いして実装してもらう必要がありました。
GraphQLでは１回のリクエストで取得できるようになります！
サーバーとクライアントがスキーマ定義を共有できる
サーバー、iOSクライアント、Androidクライアントで共通のスキーマ定義を共有します。
リクエスト、レスポンスの型が定義されているのでNullableなのかNotNullなのか数値なのか文字列なのかと悩むことはもうありません！
少し困ったこと
Apolloが生成するモデルクラスはSerializableやParcelableを実装していません。そのためIntentに入れといてActivityやServiceへ渡すことはできません。
Apolloの思想では、ActivityやServiceへはIDのみを渡してIDをキーにキャッシュから読み込めばいいでしょという感じです。 既存の実装によってはAPIをRESTからGraphQLへ変更する際に少し手間がかかる可能性があります。
最後に
現在、Web APIをRESTからGraphQLへ置き換えている最中です。 その中で得た知見を今後、紹介できればと思います。
リブランディング連載一覧
- 1. JapanTaxiのアプリリニューアルプロジェクト VPoE 吉田
- 2. ネーミングについて マーケター 中川
- 3. アプリデザインについて デザイナー 室津
- 4. iOSの開発裏話 iOSエンジニア 今入
- 5. Androidの開発裏話 Androidエンジニア 祖父江
- 6. サーバサイドの開発裏話 サーバサイドエンジニア 水戸
- 7. SREの開発裏話 SREエンジニア
- 8. アプリを世に広めるために マーケター
