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 スキーマ設計基本方針の案 その2
Search
daichitakahashi
September 12, 2023
Technology
0
250
GraphQL スキーマ設計基本方針の案 その2
どこかでつかったGraphQLスキーマ設計資料
daichitakahashi
September 12, 2023
Tweet
Share
More Decks by daichitakahashi
See All by daichitakahashi
GraphQL スキーマ設計基本方針の案 その1
daichitakahashi
0
120
GraphQL スキーマ設計基本方針の案 その3
daichitakahashi
0
140
Other Decks in Technology
See All in Technology
(非公式) AWS Summit Japan と 海浜幕張 の歩き方 2025年版
coosuke
PRO
1
240
活きてなかったデータを活かしてみた話 / Shirokane Kougyou vol 19
sansan_randd
1
290
Contract One Engineering Unit 紹介資料
sansan33
PRO
0
6.4k
開発効率と信頼性を両立する Ubieのプラットフォームエンジニアリング
teru0x1
0
140
技術職じゃない私がVibe Codingで感じた、AGIが身近になる未来
blueb
0
120
(新URLに移行しました)FASTと向き合うことで見えた、大規模アジャイルの難しさと楽しさ
wooootack
0
700
ユーザーのプロフィールデータを活用した推薦精度向上の取り組み
yudai00
0
320
新規プロダクト開発、AIでどう変わった? #デザインエンジニアMeetup
bengo4com
0
450
堅牢な認証基盤の実現 TypeScriptで代数的データ型を活用する
kakehashi
PRO
2
220
Autonomous Database サービス・アップデート (FY25)
oracle4engineer
PRO
2
770
CI/CDとタスク共有で加速するVibe Coding
tnbe21
0
150
ゆるSRE #11 LT
okaru
1
600
Featured
See All Featured
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
10
900
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
45
7.3k
Rails Girls Zürich Keynote
gr2m
94
14k
Typedesign – Prime Four
hannesfritz
42
2.7k
Reflections from 52 weeks, 52 projects
jeffersonlam
350
20k
4 Signs Your Business is Dying
shpigford
184
22k
Fireside Chat
paigeccino
37
3.5k
BBQ
matthewcrist
89
9.7k
Why You Should Never Use an ORM
jnunemaker
PRO
56
9.4k
It's Worth the Effort
3n
184
28k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
6
690
KATA
mclloyd
29
14k
Transcript
GraphQL "スキーマ設計基本方針"の案 その2
命名規則
型名はPascalCase, フィールド名は camelCase
イニシャリズム、アクロニムも先頭の文字だけ 大文字にする SSO や HTTP のような名前と相性が悪いコード生成ツールが ある。
enumはUPPER_SNAKE_CASEにする 統一されていることが重要
scalarを活用する
scalarを定義することで書式やルールをもつ値を表現すること ができる。
B/Eが得られるメリット (Go - gqlgenの場合)
変換処理を書くことで、リゾルバーでは変換されたデータを受 け取ることができる。
F/Eが得られるメリット (graphql-codegenの場合)
スキーマからmockデータを生成するライブラリで、scalarに 対するダミーデータのデータ形式を指定できたりする。
後方互換性を保つ
GraphQLの基本思想はバージョンレス。 少なくとも一度の更新でフィールドの非推奨化と削除を同時に 行ってはならない。
フィールドを非推奨化するには @deprecated ディレクティ ブを使用する。
MutationのInputとPayload
Mutationの引数はそれぞれ専用のInput1つに する?
古いRelayの仕様の名残らしく、あまりメリットはない。 長いものには巻かれろ(?)
Mutationはそれぞれ専用のPayloadを返す
大前提として、Mutationは更新されたリソースを返 すべき クライアントライブラリがキャッシュを自動的に更新すること ができる。
リソースをそのまま返してしまうと、追加で返したいフィール ドが増えた場合に破壊的変更となってしまう。 => 専用のPayload型を使おう
Mutationを多機能にしない
実装やメンテナンスのコストが跳ね上がるため、ひとつの Mutationに持たせる機能は1つだけになるようにする。
"データ型+操作(作成/更新/削除)"の単位でmutationを切ると 大変なことになる。
None
以下のようなクエリを書くことで、一つのクエリを使って選択 的なデータ更新を行うことはできる。 @include とは逆の @skip ディレクティブもある。
セキュリティ関連
GraphQLではクライアントが任意のクエリを投げることができ る。 ↓ 要求された全てのフィールドを解決しようとすると サーバーに想定外の負荷がかかってしまう場合がある
クエリの複雑性に制限をかける
クエリの複雑性=8
クエリをパースした後に複雑性(complexity)を計算する。 複雑性が一定以上であれば、フィールドの解決を一切行わずに エラーを返すことができる。
None
gqlgenでは以下のようにフィールド単位の複雑性の計算方法を 設定することができる。 mailAccounts フィールドは、解決するまで項目数がわか らない 仕様で上限が決まっている場合には、その上限いっぱいにデ ータを返すことを想定して計算する (あまりやりたくないパターン)
クエリの複雑性=24
ページネーションされるフィールドでは、ペー ジあたりの最大項目数を引数として受ける
アドレス帳の1ページ目にある連絡先を取得するクエリ。
引数としてページあたりの最大項目数を受けているため、クエ リから複雑性を導くことができる。
クエリの複雑性=202
ページあたりの項目数を引数にすることで、複雑性の計算が 簡単になる "ページあたりの項目数"の決定は本来F/Eの責務 スキーマでデフォルト値を記述することもできる B/Eでは有効な値の範囲を決めておく必要がある 範囲を示すディレクティブがあっても良い @range(min: 1, max: 200)
このようなクエリでも、複雑性を計算して受け入れるかどうか を合理的に判定することができる。
複雑性の閾値は計測しながら決めていくしかないようです。
Introspection/GraphiQL ぐ ら ふ ぃ か る の無効化
パブリックAPIでない限り、本番環境ではGraphiQLのようなプ レイグラウンドを公開するべきでない。 同様に、スキーマ情報を取得できるIntrospectionも無効化し ておく。 OWASP Cheat Sheet Series - GraphQL
Cheat Sheet
エラーレスポンスに実装の情報が入り 込まないようにする
GraphQLに限りませんが、エラーレスポンスにスタックトレー スやライブラリのエラーメッセージなどを含まないようにしま しょう。