1. @saboyutaka
GraphQLはどんな時に使うか
合同会社春秋
Tech Base Okinawa 2023
〜目的や用途を整理して導入のヒントを共有する〜

2. 自己紹介
• @saboyutaka, さぼ, 立花 豊
• 合同会社春秋 共同代表/アーキテクト
• CODEBASEプログラミング講座 講師
• 福岡(~21) → 東京(~27) → 沖縄(27~, 8年目)
• Ruby, PHP, TypeScript, Python
• GraphQL/Rails/Laravel/TypeScript/React.js/Vue.js/Azure/
AWS/Servelss/データ基盤

3. 合同会社春秋
• 2022年7月, 2名で創業
• 現在6名(全員ITエンジニア, 4名はITエンジニア未経験から採用)
• 受託開発メイン(Rails, Laravel, React, Vue)
春秋
• 沖縄にITエンジニアを増やす
• 人材教育に力入れてます
• 県内で異業種からの転職からの採用を軸
• 東京水準の仕事・給与・労働環境
※ 沖縄の給与の中央値は330万円
💡 裏のトークで弊社の新垣さんが未経験からITエンジニアに転身した話してます

4. me and GraphQL
• Software Design
• 2021年8月号 第2特集 GraphQLでかなえる効率的なデータ通信
• Zenn
• GraphQLが解決する問題とその先のユースケース
• Qiita
• GraphQLの特徴を分解する ~API インターフェース・Universal BFF・API
Gateway~
• GraphQLはサーバーサイド実装のベストプラクティスとなるか
• GraphQLの全体像とWebApp開発のこれから
• 登壇
• グラフモデルとSoEとGraphQL @TECH STAND #7 2022/03/03
• サーバーサイドから見るGraphQL @ Servelss Meetup #19 2021/03/31

5. 今日話したいこと
• GraphQLを体系的に話せるようになってきた
• 最近、GraphQLじゃなくてRESTでも良くない?と思
うケースがわかってきた

6. 今日の目的
• GraphQLの目的や用途を整理する
• GraphQLを使う時、または使わない時のヒントを持
ち帰ってもらう

7. 今日話すこと
1. GraphQLのきほん
2. GraphQLの目的と設計思想
3. GraphQLで得られる恩恵
4. クライアントでのデータモデリング
5. GraphQLのアーキテクチャ特性とRESTとの比較
6. GraphQLはどんな時につかうか

8. 1. GraphQLのきほん
2. GraphQLの目的と設計思想
3. GraphQLで得られる恩恵
4. クライアントでのデータモデリング
5. GraphQLのアーキテクチャ特性とRESTとの比較
6. GraphQLはどんな時につかうか

9. GraphQLとは
• "GraphQLは、APIのクエリ言語であり、既存のデータでこれらのクエ
リを実行するためのランタイム"
• WebクライアントのためのWeb API
• Facebook発のWeb API仕様, 2015年にOSS化
• 次世代のWeb API(?)
• RESTの代替(?)
• 複雑なサービスに向いたWebAPIを作成できる

10. 最近のWebアプリケーション
• 3層アーキテクチャ(レイヤードアーキテクチャ)
• 最近はクライアントAppとサーバーAppを分けて実装する事が増えてきた
• クライアントとサーバーはWeb APIを通じてデータの取得や操作を行う
クライアント-サーバー システム
クライアント
• 利用者の目的を達成するための支援を行うアプリケーション
• PCのブラウザ, スマートフォンのApp, スマートウォッチ等の端末上で動作する
• サービスの利用者との接点となる部分
• クライアントからのリクエストを受け取り、処理を行い、レスポンスを返す
• 主に(業務)ドメインロジックとデータベースとのやりとりを担当する
• プレゼンテーション層: APIはサーバーにとってプレゼンテーション層に相当
サーバー

11. HTTPから見たGraphQL
• リクエスト
• Path: /graphql
• Method: POST
• Content Type: application/json
• レスポンス
• Content Type: application/json
POST /graphql
JSON
レスポンス

12. サーバー実装から見たGraphQL
con
fi
g/routes.rb
Ruby on Railsでの実装
app/controllers/graphql̲controller.rb
Schemaの定義と
Resolver関数の実装

13. スキーマとクエリ
• スキーマ
• データの構造と関連、操作を表現
• グラフ構造
• クエリ
• スキーマで表現されたデータの部分を取得する
• クライアントは必要なデータを自由に選択出来る
スキーマ クエリ レスポンス

14. スキーマの例
Shopify shopfront API
参照: https://graphql-kit.com/graphql-voyager/

15. サービスが複雑化するとはどういうことか
• 利用者が増える
• 売上が増える💰
• 提供する機能が増える
• コードが増える
• データや操作の種類が増える
• ネットワークトラフィックが増える
• コンピューティングリソースの消費が増える
• 開発組織が大きくなる
• コミュニケーションの量が増える

16. 1. GraphQLのきほん
2. GraphQLの目的と設計思想
3. GraphQLで得られる恩恵
4. クライアントでのデータモデリング
5. GraphQLのアーキテクチャ特性とRESTとの比較
6. GraphQLはどんな時につかうか

17. GraphQLのターゲット
Webクライアントとサーバーのやりとり(API)を効率化する
• ブラウザ, ネイティブアプリ
• 特にエンゲージメントが重要な場合
• 同期的・オンライン
• 低レイテンシ
• 不特定多数の利用者
主にWebクライアント
ターゲットではない
• 非同期・オフライン
• バッチ処理
• サーバー間連携
• レイテンシがあまり考慮されない

18. GraphQLの設計思想と目的
WebクライアントのためのAPI
データ
データや操作の一元化
ネットワーク
トラフィックの最適化
アーキテクチャ
開発
ネットワークトポロジーの最適化
上記に伴って開発プロセスの効率化

19. データや操作の一元化
• GraphQLではスキーマとクエリを使って定義・利用する
• スキーマではサービス上の全てのデータと操作が閲覧・利用できる
• クライアントと対話するAPIサーバーが1台に集約される
💡
GraphQLでは対象者(一般ユーザー, マネージャー, Admin等)や利用用途によって
スキーマとエンドポイントを分ける事はある
信頼できる唯一の情報源 (Single source of truth)

20. ネットワークトラフィックの最適化
ネットワークトラフィックも膨大な量になるとお金がかかる😭
• リクエスト・レスポンスの集積度を上げるアプローチ
• クライアントがクエリを用いて要求出来るため1回のリクエストで必要なデータが
取得出来る
• 必要以上のデータを要求せずにすむ(オーバーフェッチ問題)
• リクエストのN+1が発生しない(アンダーフェッチ問題)
• 往復回数が減る
• データの有効率が上がる
💡 グローバルに展開するサービスだとレイテンシがボトルネックになる事も
SQLで言うと
- Select *
- JOINなし

21. アーキテクチャ: ネットワークトポロジーの最適化
• マルチクライアント
• サーバーサイドでは様々な業務を行う
• ドメイン毎の要求やデータ特性が異なる
• そのため様々なソフトウェア、データベースを使い分ける必要性がある
• マイクロサービス、サービス指向アーキテクチャ
• サーバーサイドにとっても集約層となる
サービス指向アーキテクチャとAPIアグリゲーション

22. 1. GraphQLのきほん
2. GraphQLの目的と設計思想
3. GraphQLで得られる恩恵
4. クライアントでのデータモデリング
5. GraphQLのアーキテクチャ特性とRESTとの比較
6. GraphQLはどんな時につかうか

23. クライアントAppへの恩恵
• 強い型システム
• 操作やデータに型がある
• TypeScriptの型生成がしやすい
• クライアントにとって使いやすいデータ構造である場合に加工が不要になる
• 通信するサーバーが1台になることで通信の煩雑さがなくなる
• ComponentとFragmentの相性が良い(Fragment Colocation)
• クライアントでの状態同期が容易
• GraphQLクライアントが状態管理まで行う
• Subscribe(Websocket)
• そのサービスで利用できる操作・データが一覧できる

24. サーバーAppへの恩恵
• Schema Driven Development
• ドキュメントとしてのコード
• フィールドの変更でのbreaking changeが検知出来る
• ユースケース毎の実装が減る
• 拡張する場合に実装工数がリニア
• RESTに比べてデータソースの呼び出し箇所が減る
• マイクロサービス化しやすい

25. 運用・開発プロセスへ恩恵
• ネットワークコスト、計算リソースを最適化出来るチャンスがある
• クライアント・操作・フィールド単位でどのように利用されているかトラッキングできる
• フィールドの変更でのbreaking changeが検知できる
運用
開発プロセス
• Schema Driven Development
• 煩雑なAPIに比べてコミュニケーションが少なくすむ

26. 1. GraphQLのきほん
2. GraphQLの目的と設計思想
3. GraphQLで得られる恩恵
4. クライアントでのデータモデリング
5. GraphQLのアーキテクチャ特性とRESTとの比較
6. GraphQLはどんな時につかうか

27. データモデルとは
"データモデルは、おそらくソフトウェアを開発するにあたって最も重要な部分でしょう。これ
は、データモデルがソフトウェアの書き方だけではなく、
私達が解決しようとする問題に対する考え方に対して、きわめて重要な影響力を持っているため
です。アプリケーション開発者は、現実の世界(そこには人々、組織、物、行動、金銭の流れ、セ
ンサーなど)を見て、それをオブジェクトやデータ構造と、それらのデータ構造を操作するAPIに
よってモデル化します。
データモデルはソフトウェアにできること、そしてできないことに関してきわめて大きな影響を
及ぼすので、アプリケーションに適したデータモデルを選択するのは重要です。"
出典: データ指向アプリケーションデザイン 2章 データモデルとクエリ言語

28. データモデリング
データベース
サーバー
クライアント
ドメインロジック(業務) データの保持・書き込み
利用者の目的の達成の支援
エンゲージメント
WebAPI SQL(※)
• リレーショナルDB
• オブジェクトDB
• グラフDB
Active Record
Entity +
Data Mapper 疎
密
ORM
API
密 疎
or
データ層

29. データモデリングと結合
密結合
疎結合
• DRY原則と相性が良い
• 高速に構築できる可能性がある
• 大規模になると足かせになりがち
• 異なるコンテキストで用途の差異があると変換コストがかかる
• SOLID原則と相性が良い
• 他方の仕様に依存しない実装・モデリングができる
• 特定のコンテキストだけで作業ができて認知コストが下がる
• 規模が小さいとメリットを得られづらい
• コードの量や設定が増える
• 他方を変更できない場合に新たな層としてモデリングする(腐敗防止層)

30. データモデリングとRESTとGraphQL
• ユースケースとデータモデリングと計算コストがセット(固定)
• 変更はバージョニングすることで対応する
• 未来において変更がしずらい
• 作成時に現在から見える最長のスコープで設計する必要がある
REST
GraphQL
• スキーマのモデリングからユースケースを分離できる
• ユースケースはクエリが担当
• 最大でモデリングし、最小で利用できる
• 未来において変更しやすい
• モデルの変更が必要になった時に追加・削除出来る
💡 どちらでもドメインのデータモデルと密結合・疎結合なデータモデリングが出来る

31. 1. GraphQLのきほん
2. GraphQLの目的と設計思想
3. GraphQLで得られる恩恵
4. クライアントでのデータモデリング
5. GraphQLのアーキテクチャ特性と
RESTとの比較
6. GraphQLはどんな時につかうか

32. GraphQLのアーキテクチャ特性
書籍 ソフトウェアアーキテクチャの基礎 から引用する
運用特性 構造特性 横断的特性
可用性
継続性
パフォーマンス
回復性
信頼性・安全性
堅牢性
スケーラビリティ
構成容易性
拡張性
活用性・再利用性
ローカライゼーション
メンテナンス容易性
可搬性
アップグレード容易性
アクセシビリティ
長期保存性
認証・認可
合法性
プライバシー
セキュリティ
サポート容易性
ユーザビリティ

33. GraphQLとパフォーマンス
ネットワークレイテンシ
• リクエストを集積する事でレイテンシが最小化する
• ※しかし日本国内向けサービスだとレイテンシが問題として表面化しにく
•クエリで必要なデータだけ取得するためトラフィック量・通信時間が最小化する
ネットワークキャッシュ
• HTTPのレスポンスキャッシュを使えない ※一応GETでもリクエスト出来てキャッシュも出来る
• RESTではできる部分的なキャッシュができない
サーバーロジック
• リクエストが集積するため、データのアクセス回数が最小化する可能性がある
• 木構造の
fi
eldの解決を同じ高さで並行処理出来る
•全てのフィールドの解決が終わるまでレスポンスが返せないため、遅いフィールドに依存する
😊
😊
😢
😊
😢
😢
😊
GraphQL is Fast ??
⚒
• 特定少数のクライアントとのリクエスト並列度を上げる・オーバーヘッドを減らすアプローチだとgRPC
• 大量の書き込みだとストリーム処理などの別解法がある

34. GraphQL と RESTの比較
GraphQL REST
設計思想 全体・可変 部分・制約
クライアントの利用容易性 一定 endpointの増加に伴って指数関数的増加
実装コスト
fi
eldの実装コストは一定
周辺ツールの実装・運用にコストがある
endpointを実装するのは容易
用途毎のendpointが増えてくると困難
学習コスト 大きい 小さい
計算量 可変 固定
認証 HTTP, アプリ HTTP, アプリ
認可 アプリ HTTP, アプリ
キャッシュ アプリ HTTP, アプリ
ログ・監視 GraphQL用の監視が必要 リクエストベース
モデリングのしやすさ ◎ △
データモデルの進化可能性 ◎ △
破壊的変更の検知 可能 難しい
向いてるApp
複雑・変化が大きい・見た目の要求が高い
Private API
シンプル・変化が少ない
Partner API・Public API
😊
😢
🤔
🤔
🤔
😊
😊
😢
🤔 🤔
🥰
🥰

35. 1. GraphQLのきほん
2. GraphQLの目的と設計思想
3. GraphQLで得られる恩恵
4. クライアントでのデータモデリング
5. GraphQLのアーキテクチャ特性とRESTとの比較
6. GraphQLはどんな時につかうか

36. 今日のおさらい
• GraphQLのターゲットはWebクライント
• データや操作の一元化
• 最大で定義し、最小で利用する
• ネットワークトラフィックの最適化
• 集積するアプローチ
• アーキテクチャトポロジーの整理
コアコンセプト
• 強い型システム
• クライアントにとって使いやすいデータモデル
• 通信するサーバーが1台になる
• ComponentとFragmentの相性が良い(Fragment Colocation)
• クライアントでの状態同期が容易
• GraphQLクライアントが状態管理まで行う
• Subscribe(Websocket)
• そのサービスで利用できる操作・データが一覧できる
クライアント
• Schema Driven Development
• ドキュメントとしてのコード
• フィールドの変更でのbreaking changeが検知出来る
• ユースケース毎の実装が減る
• マイクロサービス化しやすい
サーバー
GraphQLの恩恵
データモデリング
• ドメインとクライアントでの密結合と疎結合
• RESTとGraphQLのモデリングのしやすさ
⚒
• GraphQLの戦略的利用: コアコンセプトやデータモデリングの部分が(非)機能要件としてクリティカルな時
• GraphQLの戦術利用: 恩恵を得る手段として採用する

37. GraphQLを検討する時の質問項目
• サービス
• サービス提供においてエンゲージメントが占める比重が大きいか
• サービスの進化速度が速いか、今後も変化し続けるか
• 開発組織が拡大し続けるか
• データモデル・スキーマ
• クラサバで異なるデータモデリングしたいか
• 扱うデータ・操作の関連が複雑か
• ネットワーク
• レイテンシやトラフィック量やオーバーヘッドの要求が高いか
• クライアントの性質
• APIコールと状態管理が煩雑か
• クライアント実装でDDDを考えた事がある?
• クラサバ間でのデータ更新・同期が頻繁に起きるか(特に書き込みが多い)
• Redux等でのデータ管理に疲れた？
• アーキテクチャ
• マルチクライアントかどうか
• 複数のデータソースがあるかどうか
• レガシーなシステム・データベースを利用するAPIを作る必要がある