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
Observability — Extending Into Incident Response
nari_ex
1
250
Azureコストと向き合った、4年半のリアル / Four and a half years of dealing with Azure costs
aeonpeople
1
280
IoTLT@ストラタシスジャパン_20251021
norioikedo
0
130
クラウドとリアルの融合により、製造業はどう変わるのか?〜クラスメソッドの製造業への取組と共に〜
hamadakoji
0
420
What's new in OpenShift 4.20
redhatlivestreaming
0
220
HonoとJSXを使って管理画面をサクッと型安全に作ろう
diggymo
0
180
SOTA競争から人間を超える画像認識へ
shinya7y
0
180
ソースを読む時の思考プロセスの例-MkDocs
sat
PRO
1
170
マルチエージェントのチームビルディング_2025-10-25
shinoyamada
0
150
Behind Postgres 18: The People, the Code, & the Invisible Work | Claire Giordano | PGConfEU 2025
clairegiordano
0
130
デザインとエンジニアリングの架け橋を目指す OPTiMのデザインシステム「nucleus」の軌跡と広げ方
optim
0
110
生成AI時代のPythonセキュリティとガバナンス
abenben
0
130
Featured
See All Featured
A Tale of Four Properties
chriscoyier
161
23k
Balancing Empowerment & Direction
lara
5
700
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
34
2.3k
It's Worth the Effort
3n
187
28k
Bash Introduction
62gerente
615
210k
Code Reviewing Like a Champion
maltzj
526
40k
What’s in a name? Adding method to the madness
productmarketing
PRO
24
3.7k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
249
1.3M
The Power of CSS Pseudo Elements
geoffreycrofte
80
6k
What's in a price? How to price your products and services
michaelherold
246
12k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
9
990
Facilitating Awesome Meetings
lara
57
6.6k
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に限りませんが、エラーレスポンスにスタックトレー スやライブラリのエラーメッセージなどを含まないようにしま しょう。