TECH STAND #7 GraphQL 2022/03/03 https://standfm.connpass.com/event/239750/

1. @saboyutaka 2022/03/03
TECH STAND #7 GraphQL
グラフモデルとSoEとGraphQL
データ指向アプリケーションデザインから見るGraphQL

2. @saboyutaka, さぼ, 立花 豊
株式会社EBILAB テックリード/アーキテクト
福岡 → 東京 → 沖縄(7年目)
GraphQL/Rails/Laravel/Python/TypeScript/React.js/Vue.js/Next.js/Nuxt.js/Azure/
Servelss/データ基盤/PowerBI
自己紹介

3. Software Design 2021年8月号 第2特集 GraphQLでかなえる効率的なデータ通信
Zenn
GraphQLが解決する問題とその先のユースケース
Qiita
GraphQLの特徴を分解する ~API インターフェース・Universal BFF・API
Gateway~
GraphQLはサーバーサイド実装のベストプラクティスとなるか
GraphQLの全体像とWebApp開発のこれから
GraphQL and Me

4. データ指向アプリケーションデザインの視点から
データモデルやシステム要件とWebAPIとGraphQLを結びつけ、
他のケースと比較しGraphQLの特徴を整理します。
今日話すこと

5. データ指向アプリケーションデザイン
"データの量や複雑さ、変化の速度が主な課題であるアプリケーションの事をデータ指向と呼びま
す。"
"今日の多くのアプリケーションは、演算指向ではなくデータ指向であり、こちらの方が大きな問
題なのです。"
2章 データモデルとクエリ言語
2.1.5 今日のリレーショナルデータベースとドキュメントデータベース
2.3 グラフ型のデータモデル
4章 エンコーディングと進化
4.3.2 サービス経由でのデータフロー: RESTとPRC
原著が出たのが2017年。主にSoRとSoIの話。2022年現在なら必ずSoEやGraphQLが書かれてい
たはず
https://amzn.to/3pxmyuv

6. "GraphQLは、APIのクエリ言語であり、既存のデータでこれらのクエリを実行するためのランタイムです。" [1]
"モダンなWebアプリの宣言型データフェッチ" [2]
WebAPI上で動く事を想定されている
HTTP-based
即時性
グラフモデルを採用している
GraphQLとは
[1] https://graphql.org/
[2] https://www.amazon.co.jp/Learning-GraphQL-Declarative-Fetching-Modern/dp/1492030716

7. データモデルとデータ間の関係
ドキュメントとリレーショナルとグラフモデル

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

9. 今日、データベースで最も使われるデータモデルはリレーショナルモデル。正規的な構造化で
データを保存し、クエリを実行出来る、リレーショナル・データベース管理システム(RDBMS)
とSQL
1970年代や1980年代にはネットワークモデルや階層モデルが提案されていた
2010年代にNoSQLの潮流の中で注目されているのがドキュメントモデルとグラフモデル
データモデルの歴史

10. リレーショナル
RDBMS, SQL
データの整合性・一貫性を維持する必
要があるビジネスデータ
関係はSQLクエリで表現する
ドキュメント グラフ
エンティティ: スキーマオンライト
関係: スキーマオンライト
MongoDB, Firestore, KVS, オブジェク
ト指向プログラミング, JSON
自己完結しているドキュメント郡で、
ドキュメント間の関係がそれほど存在
しない。多対多が苦手。
エンティティ: スキーマオンライト
関係: スキーマオンリード
エンティティ: スキーマオンリード
関連: スキーマオンリード
Neo4j, Cypher, SPARQL
潜在的にはあらゆるデータ同士に
関連が存在する、関係がとても複
雑なケースに有効
[1] https://jp.techcrunch.com/2020/02/07/2020-02-04-neo4j-4-0-graph-database-platform-brings-unlimited-scaling/
[1]
データモデルと関連性

11. データ間の関連はクライアントがSQLで取得する際にJOINすることで表現する(関係: スキーマオンリード)
SQLクライアントが関連の複雑さを負担をする
データ間の関連の数が増えるとクライアントの負担が増大する
リレーショナルモデルとグラフモデルのデータ関連度の比較
リレーショナルモデル
グラフモデル
データ間の関連はスキーマを宣言する際やデータを挿入する際に決定される(関係: スキーマオンライト)
クライアントはデータ間の関連を予め宣言された通りにクエリ・データ取得が出来る
関連が増えてもクライアントの負担は増えない

12. システム要件とデータモデル
System of Record と System of Engagement

13. 出典: System of Record と System of Engagement by Naoya Ito - Speaker Deck
https://speakerdeck.com/naoya/system-of-record-to-system-of-engagement?slide=5

14. System of Recordと
System of Engagement
出典: System of Record と System of Engagement by Naoya Ito - Speaker Deck
https://speakerdeck.com/naoya/system-of-record-to-system-of-engagement?slide=5
書かれたのは2016年
当時でもなるほどなぁと
思った
2022年の我々はSoRと
SoEをはっきり区別出来
るはず

15. システム要件とデータモデル

16. ほとんどのSoR(バックエンド)アプリケーションはリレーショナルDBを採用
する。
書込みの整合性や一貫性が保たれ、SQLクエリで柔軟にデータ加工が出来る
テーブルが疎結合に保存される、関連は読込時にクライアントが負担する
SoRとRDBとのテーブル間の関係の複雑さを解消する方法としてORMが発明
された。ORMを利用したプログラムではORMのモデルに関係を表現する。
(ORMによる抽象化)
バックエンドアプリとリレーショナルDBのデータフロー

17. 最近のサービスはフロントエンドとバックエ
ンドを分離することでSoEとSoRの責務を
きっちり分けられるようになった。※1
バックエンドは今でもリレーショナルDBと
オブジェクト指向プログラミングが主戦場
フロントエンドとバックエンド間のデータフ
ローはWebAPIを利用する。
今日、主に利用されるWebAPIの形式は
REST APIとGraphQL APIがある
フロントエンドとバックエンド間のデータフロー
※1 もちろん今でも分離されていないアプリケーションは多いが今日はWebAPIの話なのでそういうことにしておきます🙏

18. 単一のエンドポイントにクエリを発行し、クライ
アントが必要な部分のデータを一括で取得する。
スキーマの構造にグラフモデルを採用
データ構造やデータ間の関係はスキーマに予め宣
言されている。
REST
データの名前と識別子を含むURLで表現され、リソース単
体、またはリソースのリストを取得する。
複数の異なるデータを扱う場合は、それぞれURLから取得
し、クライアントアプリケーション上で組み合わせる。
データ構造が表現されたスキーマはないが、間接的なド
キュメントとしてのスキーマとしてOpenAPI Spec等がある
GraphQL
WebAPIとデータ間の関係
APIの特徴
データモデルと
データ間の関係
リスト[オブジェクト]
データ間の関係は、クライアントアプリ開発者が負担する。(スキーマなし)
データの関連が複雑な場合にクライアントの負担が大きい
データ間の関係がそれほど複雑でない場合に向いている
グラフモデル
データの関連が複雑な場合にでもクライアントの負担は
変わらない(データの関係がスキーマオンライト )
データ間の関係が複雑である場合に向いている

19. データモデリングと
インピーダンスミスマッチと
抽象化

20. ある2者間でモデリングしたデータの構造が異なる場合、変換に発生する差異をインピーダンスミスマッチという
例: プログラム(オブジェクト) リレーショナルDB(テーブル)
例: フロントエンドでのデータモデリング WebAPIのデータモデリング
特にフロントエンドでは、REST APIから取得出来るデータとの差異が発生することがある。
SoEの要件の変化の速さについていけない
UIに正解がない ≒ APIのモデリングに正解がない
またフロントエンドではバックエンドの複数のAPIを結合して1つのデータとして扱う場合もある。
その差異はフロントエンド側が負担することになる
インピーダンスミスマッチ

21. フロントエンドとバックエンドのデータモデリングのインピーダンスミスマッチを解決する目
的での負担を減らすためにBFF(Backend for Frontends)の概念が生まれた
フロントエンドのデータモデリングに沿ったデータ集約・変換するAPI
これによってフロントエンドの負担(変換処理)を減らす事ができた
複雑さを隠 するための抽象化層
GraphQLはBFF的特徴を内包している
BFF および GraphQL

22. データの関係と抽象化

23. データの関係複雑度と
システム間のデータ抽象度
REST はSoEの要求があまりないとき、小規模なサー
ビスに有効
BFF はSoEとSoRのデータモデリングが異なる、か
つ扱うデータが少ないサービスに有効(だがGraphQL
がその特徴を取り込んだので今では選択しない?)
Hasura は、SoRとSoEのデータモデリングが同形の
サービスに有効 [1]
GraphQL は、大規模で複雑なデータを扱うサービ
スに有効
[1] https://hasura.io/

24. データの種類が多い・関連性が複雑
SoRとSoEのデータモデルが異なる
SoEの比重が大きくなってきた時期
SoEの要求が高い
様々なデータありそれらが関連しあっている
例: SNS, EC, ノーコード
REST or Hasura
データの種類が少ない・関連性が低い
SoRとSoEのデータモデルが同形
サービスの立ち上げ時期
SoRが主軸なサービス
少数のテーブルが支配的, ある程度関係性がFixしてい
る
例: 帳票系, 履歴管理, 売上管理, 管理システム, ドキュ
メント管理, ブログ, Admin画面
GraphQL
どちらが向いてる？

25. APIの進化性
前方互換性と後方互換性

26. 前方互換性
未来において変化していけること。変化しやすいこと。
後方互換性
古いコードでも利用出来ること。変化しないこと。
進化性

27. REST
利用され始めるとURLやデータの内容を変更しない。そのため、後方互換性に強いといえる。
API毎に独立したデータであるため、ロジックの実行範囲とデータの利用範囲が限定的。計算量やI/Oのコストが見積もりや
すい。
API毎の利用制限がかけやすい
仕様の変更を極力行わない、パートナーAPI,パブリックAPIに向いている
GraphQL
スキーマは変化し続ける事を想定されている。そのため前方互換性に強いといえる。
クエリによって計算量やI/Oのコストが変動する、クライアントが発行するクエリを制限しづらい。 ※ 1
仕様変更を頻繁に行う、1st Party APIに向いている
RESTとGraphQLと進化性
※1 Complexity Limit や Depth Limit によってある程度制限できるが..

28. まとめ

29. データ指向アプリケーションデザインの観点から見ると、
グラフモデルを採用した、データの関係が複雑、またはデータの
抽象度がSoRとは異なる、要求の高いSoEを実現するためWebAPI
GraphQLとは

30. REST 対 GraphQL, BFF 対 GraphQL, Hasura 対 Hand-writtingの
GraphQL(Apollo等)の違いをデータの関係の複雑さと抽象度の違いを
分類した
将来においてもRESTでよいアプリケーション、またGraphQLに向い
ているアプリケーションを分類した
GraphQLと比較することで、RESTの良さを再発見することができた
まとめ