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
いま注目しているデータエンジニアリングの論点
ikkimiyazaki
0
590
pprof vs runtime/trace (FlightRecorder)
task4233
0
160
DataOpsNight#8_Terragruntを用いたスケーラブルなSnowflakeインフラ管理
roki18d
1
330
extension 現場で使えるXcodeショートカット一覧
ktombow
0
210
VCC 2025 Write-up
bata_24
0
180
Findy Team+のSOC2取得までの道のり
rvirus0817
0
320
生成AIで「お客様の声」を ストーリーに変える 新潮流「Generative ETL」
ishikawa_satoru
1
300
実装で解き明かす並行処理の歴史
zozotech
PRO
1
310
多様な事業ドメインのクリエイターへ 価値を届けるための営みについて
massyuu
0
100
"複雑なデータ処理 × 静的サイト" を両立させる、楽をするRails運用 / A low-effort Rails workflow that combines “Complex Data Processing × Static Sites”
hogelog
3
1.9k
AI Agentと MCP Serverで実現する iOSアプリの 自動テスト作成の効率化
spiderplus_cb
0
480
生成AIとM5Stack / M5 Japan Tour 2025 Autumn 東京
you
PRO
0
200
Featured
See All Featured
Keith and Marios Guide to Fast Websites
keithpitt
411
22k
Mobile First: as difficult as doing things right
swwweet
224
10k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
657
61k
Typedesign – Prime Four
hannesfritz
42
2.8k
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
Making Projects Easy
brettharned
119
6.4k
Raft: Consensus for Rubyists
vanstee
139
7.1k
Bash Introduction
62gerente
615
210k
Building an army of robots
kneath
306
46k
Unsuck your backbone
ammeep
671
58k
Writing Fast Ruby
sferik
629
62k
VelocityConf: Rendering Performance Case Studies
addyosmani
332
24k
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に限りませんが、エラーレスポンスにスタックトレー スやライブラリのエラーメッセージなどを含まないようにしま しょう。