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
React開発にStorybookとCopilotを導入して、爆速でUIを編集・確認する方法
yu_kod
1
280
成長し続けるアプリのためのテストと設計の関係、そして意思決定の記録。
sansantech
PRO
0
120
データグループにおけるフロントエンド開発
lycorptech_jp
PRO
1
110
LangSmith×Webhook連携で実現するプロンプトドリブンCI/CD
sergicalsix
1
240
Core Audio tapを使ったリアルタイム音声処理のお話
yuta0306
0
190
PO初心者が考えた ”POらしさ”
nb_rady
0
210
敢えて生成AIを使わないマネジメント業務
kzkmaeda
2
450
生成AI開発案件におけるClineの業務活用事例とTips
shinya337
0
260
AWS認定を取る中で感じたこと
siromi
1
190
Getting to Know Your Legacy (System) with AI-Driven Software Archeology (WeAreDevelopers World Congress 2025)
feststelltaste
1
130
KubeCon + CloudNativeCon Japan 2025 Recap
ren510dev
1
390
IPA&AWSダブル全冠が明かす、人生を変えた勉強法のすべて
iwamot
PRO
2
150
Featured
See All Featured
How STYLIGHT went responsive
nonsquared
100
5.6k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
50k
Visualization
eitanlees
146
16k
Stop Working from a Prison Cell
hatefulcrawdad
271
21k
Intergalactic Javascript Robots from Outer Space
tanoku
271
27k
Adopting Sorbet at Scale
ufuk
77
9.5k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
107
19k
[RailsConf 2023] Rails as a piece of cake
palkan
55
5.7k
Building Applications with DynamoDB
mza
95
6.5k
Raft: Consensus for Rubyists
vanstee
140
7k
A better future with KSS
kneath
238
17k
Git: the NoSQL Database
bkeepers
PRO
430
65k
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がツリー構造を扱いたい場合には変換処理 を入れてもらうことになる。