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
130
GraphQL スキーマ設計基本方針の案 その2
daichitakahashi
0
270
Other Decks in Technology
See All in Technology
もう外には出ない。より快適なフルリモート環境を目指して
mottyzzz
13
10k
Azure Well-Architected Framework入門
tomokusaba
1
130
Linux カーネルが支えるコンテナの仕組み / LF Japan Community Days 2025 Osaka
tenforward
1
130
20251027_findyさん_音声エージェントLT
almondo_event
2
430
AIエージェントによる業務効率化への飽くなき挑戦-AWS上の実開発事例から学んだ効果、現実そしてギャップ-
nasuvitz
5
1.2k
AI-Readyを目指した非構造化データのメダリオンアーキテクチャ
r_miura
1
320
AI時代におけるデータの重要性 ~データマネジメントの第一歩~
ryoichi_ota
0
710
20251027_マルチエージェントとは
almondo_event
1
430
ソフトウェアエンジニアの生成AI活用と、これから
lycorptech_jp
PRO
0
900
ハノーファーメッセ2025で見た生成AI活用ユースケース.pdf
hamadakoji
1
470
「最速」で Gemini CLI を使いこなそう! 〜Cloud Shell/Cloud Run の活用〜 / The Fastest Way to Master the Gemini CLI — with Cloud Shell and Cloud Run
aoto
PRO
1
180
Biz職でもDifyでできる! 「触らないAIワークフロー」を実現する方法
igarashikana
7
3.4k
Featured
See All Featured
Writing Fast Ruby
sferik
630
62k
Building Better People: How to give real-time feedback that sticks.
wjessup
369
20k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
9
1k
Testing 201, or: Great Expectations
jmmastey
45
7.7k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
333
22k
Mobile First: as difficult as doing things right
swwweet
225
10k
Code Reviewing Like a Champion
maltzj
526
40k
Bash Introduction
62gerente
615
210k
The Illustrated Children's Guide to Kubernetes
chrisshort
49
51k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
359
30k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
230
22k
Embracing the Ebb and Flow
colly
88
4.9k
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がツリー構造を扱いたい場合には変換処理 を入れてもらうことになる。