GraphQL スキーマ設計基本方針の案 その3

どこかでつかったGraphQLスキーマ設計資料

Transcript

1. ページネーションをどう実装す るか
2. ページ番号・ベース (page: Int!, pageSize: Int!) カーソル・ベース (after: String, first: Int)
3. GraphQL Cursor Connections Specification https://relay.dev/graphql/connections.htm#sec- Connection-Types
5. Cursor Connections では2つの観点が絡み合っている リソースAとリソースBの関係性を辿る ページネーション
6. リソースAとリソースBの関係性を辿る
7. Edge リソースAとリソースBのつながりを表現する中間的な型。
9. Edge が"2つのリソースの関係"がもつ情報をもたせるのに適 した場所になる。
10. 補足: Connection が付加的な情報を持つこともある
11. ページネーション
12. Cursor Connections ではページ番号を使うのではなく、 起点となる Edge.cursor から範囲を指定してデータを取っ てくる。 after: "Y3Vyc29yMg==", first: 10 Y3Vyc29yMg== のカーソルをもつオブジェクトの次の10 件を取得 before: "Y3Vyc29yMg==", last: 10 Y3Vyc29yMg== のカーソルをもつオブジェクトの手前10 件を取得
13. メリット 整合性のあるページネーションが可能 次のページの先頭に、前のページの末尾と同じデータが入 る、ということがない 無限スクロールしていくようなUIに適している オフセットが大きい数字になった場合の LIMIT ... OFFSET ... が遅い問題から解放される
14. デメリット シーク法を用いたSQLは複雑性が増す(WHERE) 隣接していないページへのジャンプが難しい データの増減がページNのデータに影響して当然、という要 件には向かない ソート方法の種類に応じて、SQLのパターンが増える。
15. ↓ 開発経験からして、大抵はこの要 件を持つような気がする。 （考えていないだけだけの可能性が大いに有。たとえばオートコンプリー トの類とか） データの増減がページNのデータに影響して当然、という要 件 これまでのB2B製品の
16. 改めて ページネーションをどう実装す るか
17. リソースAとリソースBの関係性を辿る Cursor Connections の使用に則り、 Connection/Edge/Node の型を使うのが良さそう ページネーション ページ番号・ベースかカーソル・ベースか、設計時点で要 件を満たしつつ楽な方を実装すればよいのでは？ ただし、将来的に実装しなかった方が欲しくなる可能性が あるので、両方の実装が共存できるようにしておきたい
18. 例えば・・・
20. 命名規則（案） クエリ（フィールド） カーソル・ベース users ページ番号・ベース usersByPage ページ情報 カーソル・ベース CursorBasedPageInfo ページ番号・ベース PageBasedPageInfo
21. おまけ: UIにページネーションの機能がない場 合…
22. 例えばフォルダー構造
23. 階層構造×ページネーションというパターンは見たことがな い。
24. ↓のような複雑なクエリからB/Eをどう守れば良いのか…
25. 複雑性を用いたサーバー保護の観点からフォルダー一覧もペー ジネーションできるようにした方が良い。 pageSize の上限はシステムのフォルダー作成数上限と相 談してうまいこと決める 最悪、複数回リクエストすれば良い(Apollo Clientの fetchMore )
26. GraphQL スキーマ設計ガイド 第2版 安易な気持ちで tags: [Tag!]! という定義をルールに逆 らって作ってしまいました。すると Tag はいくつかのさら なる別の型への展開を持ち、ここで complexityの計算が崩 壊しました。教訓として、DBから1アクションで取れるリス トデータであっても、スカラ型でもenumでもない場合はイ ンメモリでCursor Connections相当の構造に変換するべき です。つらいです。
27. これなら安心して処理を拒否することができる。
28. これなら処理してあげても良いかもしれない…？ （フォルダーごとに先頭3つの連絡先データを見せる）
29. と思ったが、やっぱり歪に見える。 階層ごとにページネーションが必要 全てのフォルダーに対して、子フォルダーを全て取得でき たかどうか気にしてあげる必要がある 複雑性を無駄に大きく見積もる必要がある
30. 階層構造がネックになる場合、フラットなデータ構造に変更す ることも視野に入れる。
32. シンプルになった。 その代わりに、F/Eがツリー構造を扱いたい場合には変換処理 を入れてもらうことになる。