【話し手】
佐野 健介（SANO Kensuke（そな太） ）
佐野 健介
Appify Technologies CTO。Go、
GitHub：sonatard
Twitter：@sonatard
技術分野は成熟が進み、
今回は長年、
ファーストインプレッション
日高：さっそく、
佐野：Appify Technologiesという会社に勤めていて、
日高：それぞれのアプリと通信するWeb APIプラットフォームにGraphQLを使っているということでしょうか。
佐野：ええ。アプリとサーバサイドのインタフェースにGraphQLを採用しています。GraphQL はクライアント側が欲しい情報を取得するクエリを発行し、
日高：触り始めたときもそのあたりにメリットを感じたわけですか？
佐野：最初に知ったきっかけは、
日高：実際に使ってみてどう感じましたか。私自身、
佐野：そうですね。当時はWebサービスから使い始めていたんですけど、
日高：導入のメリットはあるけど、
佐野：そんなに大げさではないと思いますが、
アプリと相性が良いクエリ
日高：GitHubがGraphQLの採用を発表した時期は2016年ごろですね。今ではGraphQLもそこそこ使われていると感じています。コミュニティも育っていっているのかなと。現在まで使ってみて印象はどのように変化しましたか？
佐野：最初は少し簡単に開発できるなという感覚でしたが、
日高：クライアント側ってだいたいWeb APIをいくつか束ねて画面に表示する情報を集めますよね。REST APIの待ち合わせやエラー処理が複数でてくると、
佐野：クライアントのアプリ開発を乱暴に分類すると、
日高：それはクエリがあるからAPIがシンプルになるという意味？
佐野：説明の前にアプリ側の設計を補足したいんですが、
日高：たしかに。ユーザー体験を考えるとキャッシュしておきたい。
佐野：GraphQLではApollo ClientのようなOSS
日高：設計でカバーしていたところをライブラリの中に押し止められる。考えることが減ると。しかし複数のAPIを1つのクエリにまとめてしまうとバックエンドはこれまでに比べて難しくなっていそうですが。
佐野：そう。これはいろいろな意見があると思うんですけど、
クエリが便利な理由
日高：それはうれしいですね。GraphQLのどんな特徴がバックエンドに寄与しているのか、
佐野：ちょっと例を使って説明してみましょうか。ショッピングアプリでプロフィール画面にユーザーの注文一覧も出したいと考えてください。
日高：えーと素朴な実装をするとプロフィールを表示するためにユーザーIDを使ってプロフィール取得Web APIを呼び出し、
佐野：そうですね。REST APIだとAPIそのものが増えたり、
日高：つまりプロフィールと注文一覧が両方取れるAPIを新設するのと同じ効果をより小さい手間で得られると。
佐野：GraphQLでは何が取得できるかをスキーマとして定義します。新規に取得できる情報を追加するときには、
日高：RESTのAPIパラメータは安易に追加できないですよね。APIのレスポンスに注文一覧が含まれてデータが大きくなると使わないときに効率的じゃないし、
佐野：もちろんGraphQLでも気を付ける点はあります。しかしスキーマがあるので問い合わせのクエリが正しいかを検証しやすい。クライアントが使わないなら、
日高：たしかにそうですね。クライアントも画面構成を変えやすくなるなら効率の良さを感じます。
複雑性に対抗する手段
佐野：バックエンドとクライアント、
GraphQLではクエリそのものに設計意図が反映できます。プロフィールと注文一覧を同時に要求されたら、
日高：いまプロフィール画面を例に話をしていたのでわかりやすいなと思ったのですが、
佐野：柔軟な表現ができるとユースケースに合わせた設計ができます。iOSやAndroid、
日高：それはすごく良いですね。一方でクエリが柔軟なばかりに複雑になるというケースはないんでしょうか。さっきの例だと注文一覧が実は時間がかかる処理だったとか。
佐野：そういうときはクエリの複雑性に制限をかけられます。Complexityが定義できて、
日高：それは知りませんでした。利用統計は便利そうです。
佐野：Apollo社はGraphQLでビジネスをしている企業です。最近ではMicrosoftとの協業やNetflixが自社クライアントをApollo製のOSSライブラリに置き換えるといった発表もありました。
日高：なるほど。広く使われているクライアントであれば学習コストも低くて済みます。
佐野：マイクロサービスでgRPCが一気に普及したのと同じように、
日高：わかります。メリットがあるのは大企業だけではないと感じてきました。もっといろいろな利用形態が生まれていい時期かもしれません。
佐野：ええ。私も自社事業で使っていますがスタートアップですよ
友達は宣言的UI
日高：GraphQLを使うことで省略できる部分が？
佐野：冒頭で触れた宣言的UIとの相性が良いという話題ですが、
日高：宣言的UIは命令的な記述ではなく、
佐野：そうです。代表的なものはWebであればReact、
日高：GraphQLと相性が良い部分はどこあたりでしょう。
佐野：基本的にビューはユーザー操作をトリガにバックエンドからデータを得て、
日高：それは夢のある話ですね。REST APIだとどうしても順序を気にすると思います。AのあとBをたたいてAとBのレスポンスを合わせて必要な情報を取り出して画面に出すデータを作る。しかし究極的には開発者は順序を気にしたいわけじゃなくてビューを作りたいだけだと。
佐野：まさにボイラーコードの大部分をGraphQLのクライアントとリアクティブシステムが隠蔽してくれるから生産性高く開発できるのだと思います。
日高：欲しいデータが多いと一度のリクエストではレスポンスがなかなか返ってこないケースもあるのでは？
佐野：パフォーマンス問題ですね。これも現在GraphQLのスペックを強化するために議論しているポイントです。プロポーザルとしてdeferディレクティブがあがっています。クエリ中のフィールドに付与するとあとから値を返せるようになります。遅いフィールドにクエリ全体が引きずられないようにするものです。
日高：それは使い勝手がよさそうです。たくさんアクセスのあるデータって多少なりとも分布に偏りがありますからね。気になるならApollo Studioなどの開発ツールでチェックできると。
将来への期待
佐野：そうですね。GraphQLは書きやすさや生産性を考えると、
日高：やりたいことを手助けしてくれるツールなんですね。
佐野：ええ。OSSという点もすばらしいですがApolloの有償プランってボトルネックの解析やチューニングに使えるものが多いんです。GraphQLを中心にビジネスをする企業がではじめているのも好ましい技術の使われ方で、
日高：今回はじめて知ったことも多かったです。
佐野：誤解されやすいというか、
日高：開拓者精神ですね。Webだけじゃなくてアプリ開発でも将来性があると聞けて良かったなと思います。
佐野：OSSに貢献する人が増えたり、
本誌最新号をチェック！
WEB+DB PRESS Vol.134
2023年4月22日発売
B5判／
定価1,628円
ISBN978-4-297-13477-8
- 特集1
仕様ファーストでいこう！
実践API設計
堅牢で、保守性に優れたWebサービスの実現 - 特集2
はじめての画像回帰テスト
Storybook&Chromaticで品質も生産性も向上！ - 特集3
画像生成AIのしくみ
Stable Diffusionの内部を探る