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

December 11, 2018

💁🏻

※本記事は Mobility Technologies の前身である JapanTaxi 時代に公開していたもので、記事中での会社やサービスに関する記述は公開当時のものです。

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

はじめに

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

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

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

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

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

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

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

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

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

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

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

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へ置き換えている最中です。その中で得た知見を今後、紹介できればと思います。

💁🏻

※本記事は Mobility Technologies の前身である JapanTaxi 時代に公開していたもので、記事中での会社やサービスに関する記述は公開当時のものです。

Mobility Technologies では共に日本のモビリティを進化させていくエンジニアを募集しています。話を聞いてみたいという方は、是非募集ページからご相談ください！