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
100
GraphQL スキーマ設計基本方針の案 その2
daichitakahashi
0
200
Other Decks in Technology
See All in Technology
Docker Desktop で Docker を始めよう
zembutsu
PRO
0
150
#TRG24 / David Cuartielles / Post Open Source
tarugoconf
0
560
EMConf JP の楽しみ方 / How to enjoy EMConf JP
pauli
2
150
エンジニアリングマネージャー視点での、自律的なスケーリングを実現するFASTという選択肢 / RSGT2025
yoshikiiida
4
3.6k
Oracle Base Database Service:サービス概要のご紹介
oracle4engineer
PRO
1
16k
I could be Wrong!! - Learning from Agile Experts
kawaguti
PRO
8
3.3k
自社 200 記事を元に整理した読みやすいテックブログを書くための Tips 集
masakihirose
2
320
KMP with Crashlytics
sansantech
PRO
0
240
WantedlyでのKotlin Multiplatformの導入と課題 / Kotlin Multiplatform Implementation and Challenges at Wantedly
kubode
0
240
Azureの開発で辛いところ
re3turn
0
240
駆け出しリーダーとしての第一歩〜開発チームとの新しい関わり方〜 / Beginning Journey as Team Leader
kaonavi
0
120
いま現場PMのあなたが、 経営と向き合うPMになるために 必要なこと、腹をくくること
hiro93n
9
7.3k
Featured
See All Featured
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
47
5.1k
VelocityConf: Rendering Performance Case Studies
addyosmani
327
24k
Navigating Team Friction
lara
183
15k
The Power of CSS Pseudo Elements
geoffreycrofte
74
5.4k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
28
9.2k
Adopting Sorbet at Scale
ufuk
74
9.2k
Embracing the Ebb and Flow
colly
84
4.5k
Building a Scalable Design System with Sketch
lauravandoore
460
33k
Java REST API Framework Comparison - PWX 2021
mraible
28
8.3k
Fantastic passwords and where to find them - at NoRuKo
philnash
50
2.9k
Measuring & Analyzing Core Web Vitals
bluesmoon
5
210
The Art of Programming - Codeland 2020
erikaheidi
53
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がツリー構造を扱いたい場合には変換処理 を入れてもらうことになる。