Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
GraphQL スキーマ設計基本方針の案 その3
Search
daichitakahashi
September 12, 2023
Technology
0
140
GraphQL スキーマ設計基本方針の案 その3
どこかでつかったGraphQLスキーマ設計資料
daichitakahashi
September 12, 2023
Tweet
Share
More Decks by daichitakahashi
See All by daichitakahashi
GraphQL スキーマ設計基本方針の案 その1
daichitakahashi
0
120
GraphQL スキーマ設計基本方針の案 その2
daichitakahashi
0
250
Other Decks in Technology
See All in Technology
生成AI時代の開発組織・技術・プロセス 〜 ログラスの挑戦と考察 〜
itohiro73
1
390
5min GuardDuty Extended Threat Detection EKS
takakuni
0
180
開発生産性を組織全体の「生産性」へ! 部門間連携の壁を越える実践的ステップ
sudo5in5k
1
1.7k
FOSS4G 2025 KANSAI QGISで点群データをいろいろしてみた
kou_kita
0
300
解析の定理証明実践@Lean 4
dec9ue
1
210
なぜ私はいま、ここにいるのか? #もがく中堅デザイナー #プロダクトデザイナー
bengo4com
0
1.3k
AI導入の理想と現実~コストと浸透〜
oprstchn
0
160
製造業からパッケージ製品まで、あらゆる領域をカバー!生成AIを利用したテストシナリオ生成 / 20250627 Suguru Ishii
shift_evolve
PRO
1
160
タイミーのデータモデリング事例と今後のチャレンジ
ttccddtoki
6
1.9k
WordPressから ヘッドレスCMSへ! Storyblokへの移行プロセス
nyata
0
350
Beyond Kaniko: Navigating Unprivileged Container Image Creation
f30
0
110
ハッカソン by 生成AIハッカソンvol.05
1ftseabass
PRO
0
150
Featured
See All Featured
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
45
7.5k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
357
30k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
124
52k
GraphQLの誤解/rethinking-graphql
sonatard
71
11k
YesSQL, Process and Tooling at Scale
rocio
173
14k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
161
15k
Into the Great Unknown - MozCon
thekraken
39
1.9k
Building Adaptive Systems
keathley
43
2.6k
How GitHub (no longer) Works
holman
314
140k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
31
2.4k
The Power of CSS Pseudo Elements
geoffreycrofte
77
5.8k
Side Projects
sachag
455
42k
Transcript
ページネーションをどう実装す るか
ページ番号・ベース (page: Int!, pageSize: Int!) カーソル・ベース (after: String, first: Int)
GraphQL Cursor Connections Specification https://relay.dev/graphql/connections.htm#sec- Connection-Types
None
Cursor Connections では2つの観点が絡み合っている リソースAとリソースBの関係性を辿る ページネーション
リソースAとリソースBの関係性を辿る
Edge リソースAとリソースBのつながりを表現する中間的な型。
None
Edge が"2つのリソースの関係"がもつ情報をもたせるのに適 した場所になる。
補足: Connection が付加的な情報を持つこともある
ページネーション
Cursor Connections ではページ番号を使うのではなく、 起点となる Edge.cursor から範囲を指定してデータを取っ てくる。 after: "Y3Vyc29yMg==", first:
10 Y3Vyc29yMg== のカーソルをもつオブジェクトの次の10 件を取得 before: "Y3Vyc29yMg==", last: 10 Y3Vyc29yMg== のカーソルをもつオブジェクトの手前10 件を取得
メリット 整合性のあるページネーションが可能 次のページの先頭に、前のページの末尾と同じデータが入 る、ということがない 無限スクロールしていくようなUIに適している オフセットが大きい数字になった場合の LIMIT ... OFFSET ...
が遅い問題から解放される
デメリット シーク法を用いたSQLは複雑性が増す(WHERE) 隣接していないページへのジャンプが難しい データの増減がページNのデータに影響して当然、という要 件には向かない ソート方法の種類に応じて、SQLのパターンが増える。
↓ 開発経験からして、大抵はこの要 件を持つような気がする。 (考えていないだけだけの可能性が大いに有。たとえばオートコンプリー トの類とか) データの増減がページNのデータに影響して当然、という要 件 これまでのB2B製品の
改めて ページネーションをどう実装す るか
リソースAとリソースBの関係性を辿る Cursor Connections の使用に則り、 Connection/Edge/Node の型を使うのが良さそう ページネーション ページ番号・ベースかカーソル・ベースか、設計時点で要 件を満たしつつ楽な方を実装すればよいのでは? ただし、将来的に実装しなかった方が欲しくなる可能性が
あるので、両方の実装が共存できるようにしておきたい
例えば・・・
None
命名規則(案) クエリ(フィールド) カーソル・ベース users ページ番号・ベース usersByPage ページ情報 カーソル・ベース CursorBasedPageInfo ページ番号・ベース
PageBasedPageInfo
おまけ: UIにページネーションの機能がない場 合…
例えばフォルダー構造
階層構造×ページネーションというパターンは見たことがな い。
↓のような複雑なクエリからB/Eをどう守れば良いのか…
複雑性を用いたサーバー保護の観点からフォルダー一覧もペー ジネーションできるようにした方が良い。 pageSize の上限はシステムのフォルダー作成数上限と相 談してうまいこと決める 最悪、複数回リクエストすれば良い(Apollo Clientの fetchMore )
GraphQL スキーマ設計ガイド 第2版 安易な気持ちで tags: [Tag!]! という定義をルールに逆 らって作ってしまいました。すると Tag はいくつかのさら
なる別の型への展開を持ち、ここで complexityの計算が崩 壊しました。教訓として、DBから1アクションで取れるリス トデータであっても、スカラ型でもenumでもない場合はイ ンメモリでCursor Connections相当の構造に変換するべき です。つらいです。
これなら安心して処理を拒否することができる。
これなら処理してあげても良いかもしれない…? (フォルダーごとに先頭3つの連絡先データを見せる)
と思ったが、やっぱり歪に見える。 階層ごとにページネーションが必要 全てのフォルダーに対して、子フォルダーを全て取得でき たかどうか気にしてあげる必要がある 複雑性を無駄に大きく見積もる必要がある
階層構造がネックになる場合、フラットなデータ構造に変更す ることも視野に入れる。
None
シンプルになった。 その代わりに、F/Eがツリー構造を扱いたい場合には変換処理 を入れてもらうことになる。