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 スキーマ設計基本方針の案 その1
Search
daichitakahashi
September 12, 2023
Technology
0
120
GraphQL スキーマ設計基本方針の案 その1
どこかでつかったGraphQLスキーマ設計資料
daichitakahashi
September 12, 2023
Tweet
Share
More Decks by daichitakahashi
See All by daichitakahashi
GraphQL スキーマ設計基本方針の案 その2
daichitakahashi
0
250
GraphQL スキーマ設計基本方針の案 その3
daichitakahashi
0
140
Other Decks in Technology
See All in Technology
KiCadでPad on Viaの基板作ってみた
iotengineer22
0
290
第4回Snowflake 金融ユーザー会 Snowflake summit recap
tamaoki
0
210
改めてAWS WAFを振り返る~業務で使うためのポイント~
masakiokuda
2
230
生成AIで小説を書くためにプロンプトの制約や原則について学ぶ / prompt-engineering-for-ai-fiction
nwiizo
6
4.1k
無意味な開発生産性の議論から抜け出すための予兆検知とお金とAI
i35_267
3
11k
整頓のジレンマとの戦い〜Tidy First?で振り返る事業とキャリアの歩み〜/Fighting the tidiness dilemma〜Business and Career Milestones Reflected on in Tidy First?〜
bitkey
2
14k
PO初心者が考えた ”POらしさ”
nb_rady
0
190
ドメイン特化なCLIPモデルとデータセットの紹介
tattaka
2
570
Delegating the chores of authenticating users to Keycloak
ahus1
0
140
MobileActOsaka_250704.pdf
akaitadaaki
0
110
KubeCon + CloudNativeCon Japan 2025 Recap by CA
ponkio_o
PRO
0
290
マネジメントって難しい、けどおもしろい / Management is tough, but fun! #em_findy
ar_tama
5
730
Featured
See All Featured
Building Adaptive Systems
keathley
43
2.6k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
50k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
29
1.8k
Done Done
chrislema
184
16k
Making the Leap to Tech Lead
cromwellryan
134
9.4k
Code Reviewing Like a Champion
maltzj
524
40k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
44
2.4k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
34
3.1k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
26k
Six Lessons from altMBA
skipperchong
28
3.9k
The Art of Programming - Codeland 2020
erikaheidi
54
13k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
34
5.9k
Transcript
GraphQL "スキーマ設計基本方針"の案 その1
IDは型を超えてユニークなもの とする
リクエストユーザーのユーザー情報を取得するクエリがあると する。
レスポンス IDに型名と主キーの情報を入れることで、オブジェクトと1:1対 応するIDを作ることができる。 IDをURLの形にしている例があったので参考に Base64エンコードしているものもよくある
Node interface, Query.node を実装する
Node interface ユニークなIDが取れる id フィールドをもつインターフェース を Node インターフェースとする。
Query.node ユニークなIDから、対応するオブジェクト(ノード)を取得す る。
先ほど取得したユーザーのIDを使って、ユーザー情報を取得す る。
レスポンス IDに紐づいたデータの型が User と一致したので、 ... on User でセレクトしたフィールドが取れる。
IDやnodeクエリをどのように 活用するか?
ユーザーが自分のユーザー情報を取得する OK
管理者がユーザー一覧を取得する
None
一覧から選択したユーザーの情報を取得する "任意のユーザー情報を取得するクエリ"が不要になる
さらにユーザーに紐づいた情報を辿る ユーザーに紐づいているメールアカウント(複数可)を取得す る
None
None
さらにMailAccountの詳細を取得する
None
1 2 3 5 4 6
ユニークなIDとnodeクエリがあると 何がうれしいか?
GraphQLでは、オブジェクト同士が関連づけられたネットワー ク(グラフ)を表現し、その関連付けを辿ることでデータにア クセスする。
ユーザー一覧を取得 ユーザーを選択してその詳細情報を確認 さらにそのユーザーが使うメールアカウントの詳細情報 を確認... 前回のクエリで取得したIDとnodeクエリによって グラフの探索を再開する。
1 2 3 5 4 6
グラフを上手に探索していくためには、オブジェクトのフィー ルドから関連するオブジェクトにアクセスできるのでなければ ならない ↓ User.mailAccounts: [MailAccount] ↓ オブジェクト同士の関連付けを型レベルで記述する強制力とな る
その1
None
その2
いずれも、UserとMailAccountの関連付けが型で表現されて いない 1つ目については2回のリクエストが必要、REST APIと変わ らない
None
ルートフィールドでは、テナン トやサービス全体に関わる情報 を取れるようにする
ルートとなる型 = Query , Mutation , Subscription ここで言うルートフィールド = node
, viewer , ...
先ほどの例… Query.node とinline fragmentsを使用することで、 Query.user のようなクエリを実装しなくても任意のユーザ ー情報が取れるようになっていた。 では、Queryにはほかにどのようなフィールドを生やすことに なるのか。
テナントやサービス全体に関わる情報 たとえば、たぶん、こんな感じになる…?
エラー発生時のレスポンスに注 意する
GraphQLでのエラーレスポンスは以下のような形になる。
エラーが発生したフィールドの値は null になっている それまでに解決できた値(username)は取得できている extentions に任意の情報を持たせることができる(エラ ーコード)
どんなフィールドを Non-Nullにするか
先ほどの例では、ユーザーに紐づいた2つのメールアカウント のデータ取得に失敗し、 "mailAccounts": [null, null] が返っていた。 もし User.mailAccounts の型が [MailAccount!]
で、2 つのうち1つのメールアカウント取得に失敗するとどうなる か…?
こうなる
仕様書に書いてある。 https://spec.graphql.org/June2018/#sec-Errors-and- Non-Nullability https://spec.graphql.org/June2018/#sec-Combining- List-and-Non-Null Since Non-Null type fields cannot
be null, field errors are propagated to be handled by the parent field. If the parent field may be null then it resolves to null, otherwise if it is a Non-Null type, the field error is further propagated to it’s parent field.
Non-Null型のフィールドはnullになることができないため、 フィールドエラーは親フィールドで処理されるように伝播し ます。親フィールドがnullである可能性がある場合、nullに 解決されます。それ以外の場合、Non-Null型である場合、 フィールドエラーはさらにその親フィールドに伝播されま す。
値の解決でエラーが発生する可能性があるフィールドは、 Nullableにしておきましょう。 そうすることで、取得できた値はそのまま使えます(F/Eがそ れを使うかどうかは別の話)。
エラーコードはenumで定義する
スキーマで定義することで、F/EとB/Eの認識の相違を防ぐこ とができる サーバーにしかわからない補足情報がある場合、それもスキ ーマで型定義しておくと良さそう(もしあれば)
None
GraphQL "スキーマ設計基本方針"の案 その2 enumはUPPER_SNAKE_CASEにする MutationのInput, Payloadは input や type としてまと
める complexityを計算して、APIサーバーを保護する 保護しやすいスキーマ設計 本番環境ではintrospection, GraphiQLを無効化する