アプリ開発備忘録

PlayStationMobile、Android、UWPの開発備忘録

アプリのバックエンドをREST APIからGraphQLに移行する事を検討する。

この連載記事について

  • 今はREST APIを使用しているがGraphQLを検討する。
    • サーバーについてはJVM-Kotlinを対象とする。
      • 既存の実装を利用しながら、少しづつ移行していくことを前提としている。
    • クライアント側の実装は主にAndroidでの話がメインとなる。
  • ライブラリ選定、実装方法を考える所までを行う。

REST APIとGraphQL

REST APIに感じている問題点

モバイルアプリでREST APIを開発していて、以下の様な事が起きています。
例えばUserという情報があります。それに対して様々なUserがあり、情報の内容や量が違います。

  • User単体を表示する画面
  • ユーザー投稿に対するUser
  • SNSのフォロー・フォロワー情報としてのUser

上記の結果、様々なUserの型が誕生し、実装時に混乱を招くことになりました。
更に、バージョン違いのエンドポイントでもV2Userなどが登場したりしたのも、手に負えない状況が加速した原因です。

GraphQLに感じている魅力

  • クライアントが必要な情報だけがクライアントの定義で返せる
    • これによって上記のUserは1つで定義して、それぞれで必要なフィールドだけをフェッチできるようにできる。
  • 既存への影響無しにどんどん新しいAPIが追加できる
    • RESTではフィールドを追加すると、そのフィールドが必要かどうかに関わらず、そのフィールドを用意するための処理を実行しなければならないが、GraphQLでは要求されなければ処理が走らないようにできる
  • スキーマからクライアントのコード生成ができるライブラリが揃っている
    • クライアントのコード生成ができるライブラリが揃っているという点と、既存への影響無しにどんどん新しいAPIが追加できるという点の複合として、Androidで使えるApollo Clientではenumがunknownとなっていて、デフォルトで未知の値を意識させるようになっている。
  • 1つのリクエストで全てが取得できるので、APIの待ち合わせ処理をしなくて良い。
    • Apollo ClientではFlowで値が取得できるので、流れてきた値で表示するだけでいい。

まとめ

RESTでのレスポンスの定義に限界を感じ始めた為、GraphQLを導入して改善を図ろうと考えました。
次はサーバーで使用するライブラリの選定を行います。
JVMのGraphQLのサーバー側の実装に使うライブラリを選定する ~ graphql-javaの実装方法 - アプリ開発備忘録