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
270
GraphQL スキーマ設計基本方針の案 その2
どこかでつかったGraphQLスキーマ設計資料
daichitakahashi
September 12, 2023
Tweet
Share
More Decks by daichitakahashi
See All by daichitakahashi
GraphQL スキーマ設計基本方針の案 その1
daichitakahashi
0
130
GraphQL スキーマ設計基本方針の案 その3
daichitakahashi
0
140
Other Decks in Technology
See All in Technology
プロダクト開発と社内データ活用での、BI×AIの現在地 / Data_Findy
sansan_randd
1
540
Behind Postgres 18: The People, the Code, & the Invisible Work | Claire Giordano | PGConfEU 2025
clairegiordano
0
150
Retrospectiveを振り返ろう
nakasho
0
130
Oracle Database@Google Cloud:サービス概要のご紹介
oracle4engineer
PRO
0
380
AI連携の新常識! 話題のMCPをはじめて学ぶ!
makoakiba
0
140
「タコピーの原罪」から学ぶ間違った”支援” / the bad support of Takopii
piyonakajima
0
150
Okta Identity Governanceで実現する最小権限の原則 / Implementing the Principle of Least Privilege with Okta Identity Governance
tatsumin39
0
180
QA業務を変える(!?)AIを併用した不具合分析の実践
ma2ri
0
160
ハノーファーメッセ2025で見た生成AI活用ユースケース.pdf
hamadakoji
1
490
ラスベガスの歩き方 2025年版(re:Invent 事前勉強会)
junjikoide
0
430
プロファイルとAIエージェントによる効率的なデバッグ / Effective debugging with profiler and AI assistant
ymotongpoo
1
370
ゼロコード計装導入後のカスタム計装でさらに可観測性を高めよう
sansantech
PRO
1
500
Featured
See All Featured
Become a Pro
speakerdeck
PRO
29
5.6k
The Invisible Side of Design
smashingmag
302
51k
Keith and Marios Guide to Fast Websites
keithpitt
411
23k
Rails Girls Zürich Keynote
gr2m
95
14k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
32
1.7k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
12
1.2k
GraphQLとの向き合い方2022年版
quramy
49
14k
Making the Leap to Tech Lead
cromwellryan
135
9.6k
Done Done
chrislema
185
16k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
162
15k
Principles of Awesome APIs and How to Build Them.
keavy
127
17k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
249
1.3M
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に限りませんが、エラーレスポンスにスタックトレー スやライブラリのエラーメッセージなどを含まないようにしま しょう。