特別連載|5. JapanTaxiアプリAndroidの開発裏話

開発部 祖父江
はじめまして!Androidアプリ開発をしている祖父江です。

これはJapanTaxi AdventCalendar 11日目の記事です。

JapanTaxiアプリのリニューアル時に新たに取り入れたGraphQLについて、Androidアプリで実際使ってみてどうだったかを紹介したいと思います。

はじめに

AndroidアプリでGraphQLを使うためにApollo GraphQL Client for Androidを使いました。

Apolloはスキーマ定義ファイルとQueryやMutationを書いた.graphqlファイルからJavaクラスを自動生成してくれるライブラリです。

また、サーバーのスキーマ定義を取得するためにApollo CLIを使います。

Apolloを用いた開発の流れ

大まかには以下のような流れで開発しています。

  1. サーバーからスキーマ定義ファイルを取得する
  2. QueryやMutationを.graphqlファイルに書く
  3. ビルドする
  4. Apolloが必要なクラスを自動生成してくれる
  5. 生成されたクラスを用いてサーバーへアクセスする

Query、Mutationはどうやって書いてる?

.graphqlファイルに書くQueryやMutationはGraphiQLGraphQL Playgroundを使ってスキーマ定義から生成されたドキュメントを参照しながら書いています。

その場でレスポンスを確認することができてとても便利です。

サーバーサイドのメンバーが環境を整えてくれていたので、簡単に試しながら作成することができました。

デバッグ方法

ApolloではHTTP通信にはOkHttpを使います。そのため実際のリクエストやレスポンスを確認したいときにはStethoを使って確認することができます。

そのためREST(Retrofit + OkHttp)とGraphQL(Apollo + OkHttp)とでAPIのログを1画面で確認しながらデバッグすることができます。

また、キャッシュ内容も同様にStethoで確認できます。

GraphQLを使ってみてよかったこと

複数のリソースを1回のリクエストで取得できちゃう

1番便利でクライアント視点で楽になることは複数リソースを1回のリクエストで取得できることです。

RESTだとリソースによりエンドポイントが別れていると思います。
そのためクライアントはサーバーへ必要な情報を取得するために複数のリクエストを送る必要がありました。

JapanTaxiアプリでの例をあげるとトップ画面で表示する情報を取得する際に以下の情報を取得します。
– お知らせの未読数
– 配車中の注文
– お気に入りショートカット

RESTではお知らせ、注文、お気に入りと異なるリソースであるため3回リクエストを送るか、画面表示で必要な情報をまとめて返す専用APIをサーバーへお願いして実装してもらう必要がありました。

GraphQLでは1回のリクエストで取得できるようになります!

サーバーとクライアントがスキーマ定義を共有できる

サーバー、iOSクライアント、Androidクライアントで共通のスキーマ定義を共有します。

リクエスト、レスポンスの型が定義されているのでNullableなのかNotNullなのか数値なのか文字列なのかと悩むことはもうありません!

少し困ったこと

Apolloが生成するモデルクラスはSerializableやParcelableを実装していません。
そのためIntentに入れといてActivityやServiceへ渡すことはできません。

Apolloの思想では、ActivityやServiceへはIDのみを渡してIDをキーにキャッシュから読み込めばいいでしょという感じです。
既存の実装によってはAPIをRESTからGraphQLへ変更する際に少し手間がかかる可能性があります。

最後に

現在、Web APIをRESTからGraphQLへ置き換えている最中です。
その中で得た知見を今後、紹介できればと思います。

リブランディング連載一覧

JapanTaxiでは、ITの力で「移動で人を幸せに。」を実現するための一連のサービス開発に取り組んでいます。全部署にてメンバーも積極的に募集しているので、興味のある方はWantedlyもぜひご覧ください!

JapanTaxiに興味を持ったら、まずはお話しませんか?