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
260
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
ゼロから始めるSREの事業貢献 - 生成AI時代のSRE成長戦略と実践 / Starting SRE from Day One
shinyorke
PRO
0
120
Microsoft Defender XDRで疲弊しないためのインシデント対応
sophiakunii
1
320
ポストコロナ時代の SaaS におけるコスト削減の意義
izzii
1
470
Maintainer Meetupで「生の声」を聞く ~講演だけじゃないKubeCon
logica0419
0
110
LLM拡張解体新書/llm-extension-deep-dive
oracle4engineer
PRO
23
6.3k
AWS CDK 入門ガイド これだけは知っておきたいヒント集
anank
5
750
SRE不在の開発チームが障害対応と 向き合った100日間 / 100 days dealing with issues without SREs
shin1988
2
2.1k
Delegating the chores of authenticating users to Keycloak
ahus1
0
190
Talk to Someone At Delta Airlines™️ USA Contact Numbers
travelcarecenter
0
160
Figma Dev Mode MCP Serverを用いたUI開発
zoothezoo
0
230
AIでテストプロセス自動化に挑戦する
sakatakazunori
1
530
ソフトウェアテストのAI活用_ver1.25
fumisuke
1
610
Featured
See All Featured
How to Ace a Technical Interview
jacobian
278
23k
Rails Girls Zürich Keynote
gr2m
95
14k
Optimizing for Happiness
mojombo
379
70k
The Straight Up "How To Draw Better" Workshop
denniskardys
235
140k
Designing for Performance
lara
610
69k
Music & Morning Musume
bryan
46
6.7k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
21
1.3k
Being A Developer After 40
akosma
90
590k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
138
34k
What's in a price? How to price your products and services
michaelherold
246
12k
Side Projects
sachag
455
42k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
229
22k
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に限りませんが、エラーレスポンスにスタックトレー スやライブラリのエラーメッセージなどを含まないようにしま しょう。