ちょっと気になる隣の技術畑

第3回 アプリ開発の福音となるGraphQL

この記事を読むのに必要な時間:およそ 3.5 分

画像

【話し手】
佐野 健介(SANO Kensuke(そな太))

Appify Technologies CTO。Go,React,Jetpack Composeのエンジニアです。最近は宣言的UI,GraphQL,Reactive Systemを中心にインプットをしています。

GitHub:sonatard
Twitter:@sonatard

技術分野は成熟が進み,新しい領域が急激に増えています。本コーナーでは技術へのタッチポイントを増やすことを目標に,各分野で活躍されている方をお迎えします。

今回は長年,GraphQLを追いかけている佐野さんにWebフロントだけでなくアプリ開発でも活きるメリットを語っていただきます。

ファーストインプレッション

日高:さっそく,自己紹介からお願いできますか?

佐野:Appify Technologiesという会社に勤めていて,今やっていることはノーコードでアプリをリリースできるサービスです。そこでAndroidとiOS,両方を扱っています。

日高:それぞれのアプリと通信するWeb APIプラットフォームにGraphQLを使っているということでしょうか。

佐野:ええ。アプリとサーバサイドのインタフェースにGraphQLを採用しています。GraphQL はクライアント側が欲しい情報を取得するクエリを発行し,レスポンスを返します。これが宣言的UIに代表されるリアクティブプログラミングとの相性が良いとも感じていて,アプリもAndroidはJetpack Compose,iOSではSwiftUIと宣言的UIをフルに使って書いていますね。その背景とかもお伝えしたいなと思っています。

日高:触り始めたときもそのあたりにメリットを感じたわけですか?

佐野:最初に知ったきっかけは,現職の同僚からGraphQLを使ってみたいと話があり,簡単な社内ツールで使ってみたところからだったと思います。機会があってプロダクション環境に投入したのが2019年ぐらいですね。

日高:実際に使ってみてどう感じましたか。私自身,ふわっとした理解でとどまっているのでいろいろうかがいたいです。

佐野:そうですね。当時はWebサービスから使い始めていたんですけど,やっぱり1つのクエリで必要な情報を取ってこれる体験がいいですね。すごく楽にアプリが作れる実感がありました。ただGraphQLは,はじめて触ったときの印象と使いこなしたときの印象がだいぶ違うツールなのかなと思っています。

日高:導入のメリットはあるけど,ちょっと触るぐらいでは理解されにくい。使いこなすのにコツがいると?

佐野:そんなに大げさではないと思いますが,それこそ最初に世の中に認知されはじめたタイミングはGitHubのWeb APIをGraphQLでたたけるよとニュースになったときじゃないかな。あのとき,私が思ったことは「なんかREST APIと比べて,いらないデータを取らなくて済むんだな」という感想しか持っていなくて。当時はずいぶん損してたなと(笑⁠⁠。

アプリと相性が良いクエリ

日高:GitHubがGraphQLの採用を発表した時期は2016年ごろですね。今ではGraphQLもそこそこ使われていると感じています。コミュニティも育っていっているのかなと。現在まで使ってみて印象はどのように変化しましたか?

佐野:最初は少し簡単に開発できるなという感覚でしたが,知れば知るほどクライアント側での開発効率が上がるという想像以上の経験をしています。

日高:クライアント側ってだいたいWeb APIをいくつか束ねて画面に表示する情報を集めますよね。REST APIの待ち合わせやエラー処理が複数でてくると,考えることが多くなって大変です。こういう課題に対して必要な情報がクエリで取れるGraphQLのメリットが活きてくるんでしょうか。

佐野:クライアントのアプリ開発を乱暴に分類すると,Web APIをたたいてデータを取って来るところと,画面に表示するビューを作るっていう2つが大きいと思うんです。インタフェースがGraphQLになると,まずWeb APIをたたくところがめちゃくちゃ簡単になる。

日高:それはクエリがあるからAPIがシンプルになるという意味?

佐野:説明の前にアプリ側の設計を補足したいんですが,画面遷移の効率を考えるとデータを取ってきてローカルに保存する必要性が出てきます。遷移ごとに何度もWeb APIをたたくとずいぶん待つことになるので,できるだけ避けたいわけです。宣言的UIの世界ではReduxなど設計で工夫して対応していきます。

日高:たしかに。ユーザー体験を考えるとキャッシュしておきたい。

佐野:GraphQLではApollo ClientのようなOSSOpen Source Softwareのクライアントライブラリが提供されていてキャッシュがとても簡単になります。丸ごと処理を書かなくてよいので,まず,ここですごい楽だと感じます。

日高:設計でカバーしていたところをライブラリの中に押し止められる。考えることが減ると。しかし複数のAPIを1つのクエリにまとめてしまうとバックエンドはこれまでに比べて難しくなっていそうですが。

佐野:そう。これはいろいろな意見があると思うんですけど,私としては実装コストもほとんど変わらない印象です。それよりもGraphQLを入れたことによって,クライアントのビューの仕様に依存してWeb APIを変えなければいけないというコミュニケーションがなくなりました。そこが一番バックエンドを開発していてうれしいところです。

クエリが便利な理由

日高:それはうれしいですね。GraphQLのどんな特徴がバックエンドに寄与しているのか,具体的に教えてください。

佐野:ちょっと例を使って説明してみましょうか。ショッピングアプリでプロフィール画面にユーザーの注文一覧も出したいと考えてください。

日高:えーと素朴な実装をするとプロフィールを表示するためにユーザーIDを使ってプロフィール取得Web APIを呼び出し,合わせて注文一覧を引くWeb APIを作る感じですね。

佐野:そうですね。REST APIだとAPIそのものが増えたり,パラメータが増えたりするはずです。GraphQLだとクライアントが欲しいデータを問い合わせるクエリを書いて,サーバサイドと通信します。1つのクエリでユーザーIDも注文一覧も受け取るように変更できます。APIを分けなくていいし「このユーザーのプロフィールと注文一覧が一緒に欲しい」とクエリ上で表現できるので直感的です。

日高:つまりプロフィールと注文一覧が両方取れるAPIを新設するのと同じ効果をより小さい手間で得られると。

佐野:GraphQLでは何が取得できるかをスキーマとして定義します。新規に取得できる情報を追加するときには,スキーマにフィールドを追加します。またクライアントは必要なフィールドだけをクエリに記述して取得します。そのため新規にフィールドを追加しても既存画面のレスポンスには影響しないので,すごく追加しやすい。

日高:RESTのAPIパラメータは安易に追加できないですよね。APIのレスポンスに注文一覧が含まれてデータが大きくなると使わないときに効率的じゃないし,互換性の検証が増えてしまって品質面で気を付けなきゃ……という負担もありそうです。

佐野:もちろんGraphQLでも気を付ける点はあります。しかしスキーマがあるので問い合わせのクエリが正しいかを検証しやすい。クライアントが使わないなら,そもそもデータを送らない。送ってこないなら振る舞いは変わらないので影響ないよね,と論理的に安全だと判断できます。

日高:たしかにそうですね。クライアントも画面構成を変えやすくなるなら効率の良さを感じます。

著者プロフィール

日高正博(ひだかまさひろ)

Androidの開発者カンファレンスDroidKaigiや技術書イベントの技術書典を主宰。技術の共有やコミュニケーションに興味があり,ひつじがトレードマーク。(イラスト:shatiko)

GitHub:mhidaka
Twitter:@mhidaka
URL:https://techbooster.booth.pm/