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
120
GraphQL スキーマ設計基本方針の案 その3
どこかでつかったGraphQLスキーマ設計資料
daichitakahashi
September 12, 2023
Tweet
Share
More Decks by daichitakahashi
See All by daichitakahashi
GraphQL スキーマ設計基本方針の案 その1
daichitakahashi
0
110
GraphQL スキーマ設計基本方針の案 その2
daichitakahashi
0
210
Other Decks in Technology
See All in Technology
Data-centric AI入門第6章:Data-centric AIの実践例
x_ttyszk
1
400
The Future of SEO: The Impact of AI on Search
badams
0
190
プロセス改善による品質向上事例
tomasagi
2
2.5k
Platform Engineeringは自由のめまい
nwiizo
4
2.1k
全文検索+セマンティックランカー+LLMの自然文検索サ−ビスで得られた知見
segavvy
2
100
2025-02-21 ゆるSRE勉強会 Enhancing SRE Using AI
yoshiiryo1
1
330
データ資産をシームレスに伝達するためのイベント駆動型アーキテクチャ
kakehashi
PRO
2
530
PHPカンファレンス名古屋-テックリードの経験から学んだ設計の教訓
hayatokudou
2
270
偶然 × 行動で人生の可能性を広げよう / Serendipity × Action: Discover Your Possibilities
ar_tama
1
1.1k
Classmethod AI Talks(CATs) #16 司会進行スライド(2025.02.12) / classmethod-ai-talks-aka-cats_moderator-slides_vol16_2025-02-12
shinyaa31
0
110
『衛星データ利用の方々にとって近いようで触れる機会のなさそうな小話 ~ 衛星搭載ソフトウェアと衛星運用ソフトウェア (実物) を動かしながらわいわいする編 ~』 @日本衛星データコミニティ勉強会
meltingrabbit
0
140
Oracle Cloud Infrastructure:2025年2月度サービス・アップデート
oracle4engineer
PRO
1
210
Featured
See All Featured
The Straight Up "How To Draw Better" Workshop
denniskardys
232
140k
A designer walks into a library…
pauljervisheath
205
24k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
46
2.3k
Product Roadmaps are Hard
iamctodd
PRO
50
11k
Art, The Web, and Tiny UX
lynnandtonic
298
20k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
33
2.8k
Agile that works and the tools we love
rasmusluckow
328
21k
The Cult of Friendly URLs
andyhume
78
6.2k
Statistics for Hackers
jakevdp
797
220k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
53k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
27
1.9k
Imperfection Machines: The Place of Print at Facebook
scottboms
267
13k
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がツリー構造を扱いたい場合には変換処理 を入れてもらうことになる。