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 Schema Design @ Scale
Search
Marc-Andre Giroux
November 07, 2018
Programming
5
2.1k
GraphQL Schema Design @ Scale
GraphQL Schema Design and Tooling @ GitHub
Marc-Andre Giroux
November 07, 2018
Tweet
Share
More Decks by Marc-Andre Giroux
See All by Marc-Andre Giroux
It Depends - Examining GraphQL Myths & Assumptions
xuorig
0
90
So you Want to Distribute your GraphQL Schema?
xuorig
4
820
So you Want to Distribute your GraphQL Schema?
xuorig
0
560
Continuous Evolution of GraphQL Schemas @ GitHub
xuorig
3
2.1k
GraphQL à Shopify
xuorig
0
230
Exploring GraphQL
xuorig
0
260
GraphQL @ Shopify
xuorig
6
1.6k
GraphQL on Rails
xuorig
2
340
From REST to GraphQL
xuorig
9
1.2k
Other Decks in Programming
See All in Programming
Rails産でないDBを Railsに引っ越すHACK - Omotesando.rb #110
lnit
1
160
Java on Azure で LangGraph!
kohei3110
0
110
つよそうにふるまい、つよい成果を出すのなら、つよいのかもしれない
irof
1
280
KotlinConf 2025 現地で感じたServer-Side Kotlin
n_takehata
1
190
AIコーディング道場勉強会#2 君(エンジニア)たちはどう生きるか
misakiotb
1
100
Perlで痩せる
yuukis
1
680
Development of an App for Intuitive AI Learning - Blockly Summit 2025
teba_eleven
0
110
Cline指示通りに動かない? AI小説エージェントで学ぶ指示書の書き方と自動アップデートの仕組み
kamomeashizawa
1
410
Elixir で IoT 開発、 Nerves なら簡単にできる!?
pojiro
1
120
FastMCPでMCPサーバー/クライアントを構築してみる
ttnyt8701
2
130
実践ArchUnit ~実例による検証パターンの紹介~
ogiwarat
2
250
OpenNext + Hono on Cloudflare でイマドキWeb開発スタックを実現する
rokuosan
0
120
Featured
See All Featured
Stop Working from a Prison Cell
hatefulcrawdad
269
20k
Connecting the Dots Between Site Speed, User Experience & Your Business [WebExpo 2025]
tammyeverts
4
130
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.3k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
106
19k
Visualization
eitanlees
146
16k
Fireside Chat
paigeccino
37
3.5k
BBQ
matthewcrist
89
9.7k
Build your cross-platform service in a week with App Engine
jlugia
231
18k
Side Projects
sachag
454
42k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
357
30k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
8
650
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
35
2.3k
Transcript
Marc-Andre Giroux @___xuorig___ GraphQL Summit - Nov 7th 2018 GraphQL
Schema Design @ scale
about { xuorig } • Montreal, Canada ☃ • My
3rd GraphQL Summit • I work at GitHub! 2
3
GraphQL @ GitHub • 200+ engineers working on GraphQL schema
• Teams have to move quickly • Public and Internal Schema + Enterprise. 4
GraphQL @ GitHub: Challenges • Keeping a high quality public
API across many teams and use cases. • Small API team • Best practices are still emerging, lots and lots of PR reviews to go through, and many new use cases appearing every week. 5
Why GraphQL? 6
A type system to express possibilities 7
Declarative: Clients select what they need and nothing more 8
Why do we design? 9
Why we design • Build APIs that are easier to
evolve: Best way to mitigate breaking changes we don't know about yet • Build APIs that are easier to reason about 10
GraphQL Schema Design 11
Misconceptions 12
In a complex application GraphQL is rarely an interface to
your database 13
Your GraphQL Schema does not need to match your existing
REST resources 14
It also does not have to be a 1:1 mapping
to your UI 15
The real power of GraphQL 16
GraphQL lets us model an interface to our core domain
17
For a lot of us, it is often an opportunity
to design from scratch (and maybe get it right this time? ) 18
To let go of our coupling to our database schema,
our REST resources or our UI 19
Major to a well designed GraphQL API 20
21
• Be an expert at your domain, understand the ins
and out 21
• Be an expert at your domain, understand the ins
and out • Be an expert at GraphQL specific design 21
But there's one problem... 22
23
Rarely the same people! 24
API First 25
Built by the product team 26
Helped by the API team! ❤ 27
Design Tips 28
Design Tips 29
Guiding Principles 30
Guiding Principles 31 (and some cool tools)
Design for behaviors or use cases over data 32
Anemic GraphQL ™ 33
34
35
36
37
38
39
40
Atomicity vs Granularity 41
42
Let's go back a few years... 43
Problem: Multiple clients with very different needs 44
45 Backend For Frontend Pattern http://philcalcado.com/2015/09/18/the_back_end_for_front_end_pattern_bff.html
46 Netflix: Client Optimized API Adapters https://medium.com/netflix-techblog/embracing-the-differences-inside-the-netflix-api-redesign
47
In a way... GraphQL is our BFF / Client Adapter
48
Declarative & Client Centric 49
Select * 50
Select * 51
type User { billingInfo: BillingInfo! email: String! login: String! fullName:
String! recentIssues: [Issue!]! repositories: [Repository!]! reviewRequests: [ReviewRequest!]! isOwner(repositoryID: ID!): Boolean! starredRepositories: [Repository!]! } 52
type User { billingInfo: BillingInfo! email: String! login: String! fullName:
String! recentIssues: [Issue!]! repositories: [Repository!]! reviewRequests: [ReviewRequest!]! isOwner(repositoryID: ID!): Boolean! starredRepositories: [Repository!]! } 53
type User { billingInfo: BillingInfo! email: String! login: String! fullName:
String! recentIssues: [Issue!]! repositories: [Repository!]! reviewRequests: [ReviewRequest!]! isOwner(repositoryID: ID!): Boolean! starredRepositories: [Repository!]! } 54
type User { billingInfo: BillingInfo! email: String! login: String! fullName:
String! recentIssues: [Issue!]! repositories: [Repository!]! reviewRequests: [ReviewRequest!]! isOwner(repositoryID: ID!): Boolean! starredRepositories: [Repository!]! } 55
type User { billingInfo: BillingInfo! email: String! login: String! fullName:
String! recentIssues: [Issue!]! repositories: [Repository!]! reviewRequests: [ReviewRequest!]! isOwner(repositoryID: ID!): Boolean! starredRepositories: [Repository!]! } 56
type User { billingInfo: BillingInfo! email: String! login: String! fullName:
String! recentIssues: [Issue!]! repositories: [Repository!]! reviewRequests: [ReviewRequest!]! isOwner(repositoryID: ID!): Boolean! starredRepositories: [Repository!]! } 57
type User { billingInfo: BillingInfo! email: String! login: String! fullName:
String! recentIssues: [Issue!]! repositories: [Repository!]! reviewRequests: [ReviewRequest!]! isOwner(repositoryID: ID!): Boolean! starredRepositories: [Repository!]! } 58
type User { billingInfo: BillingInfo! email: String! login: String! fullName:
String! recentIssues: [Issue!]! repositories: [Repository!]! reviewRequests: [ReviewRequest!]! isOwner(repositoryID: ID!): Boolean! starredRepositories: [Repository!]! } 59
type User { billingInfo: BillingInfo! email: String! login: String! fullName:
String! recentIssues: [Issue!]! repositories: [Repository!]! reviewRequests: [ReviewRequest!]! isOwner(repositoryID: ID!): Boolean! starredRepositories: [Repository!]! } 60
type User { billingInfo: BillingInfo! email: String! login: String! fullName:
String! recentIssues: [Issue!]! repositories: [Repository!]! reviewRequests: [ReviewRequest!]! isOwner(repositoryID: ID!): Boolean! starredRepositories: [Repository!]! } 61
type User { billingInfo: BillingInfo! email: String! login: String! fullName:
String! recentIssues: [Issue!]! repositories: [Repository!]! reviewRequests: [ReviewRequest!]! isOwner(repositoryID: ID!): Boolean! starredRepositories: [Repository!]! } 62
type User { billingInfo: BillingInfo! email: String! login: String! fullName:
String! recentIssues: [Issue!]! repositories: [Repository!]! reviewRequests: [ReviewRequest!]! isOwner(repositoryID: ID!): Boolean! starredRepositories: [Repository!]! } 63
type User { billingInfo: BillingInfo! email: String! login: String! fullName:
String! recentIssues: [Issue!]! repositories: [Repository!]! reviewRequests: [ReviewRequest!]! isOwner(repositoryID: ID!): Boolean! starredRepositories: [Repository!]! } 64
We shouldn't be afraid of adding use cases or client
specific fields if it fits a domain use case 65
Stay away from trying to build a "One Size Fits
All" API 66
and embrace the different use cases and clients 67
Prefer highly optimized fields over generic/smart fields 68
69
70
Design @ Scale: GitHub's Tooling 71
72 Checked-in SDL
73 Checked-in SDL
74
75
76
77
78 ) GraphQL Doctor
79
80
81
Sometimes we make mistakes 82
83
84
85
86
87
88
89 Fake it 'till you make it!
90
Making the change 91
Who is using the field? 92
How much is it being used? 93
No Select *: We know exactly how our schema is
used! 94
95 query { viewer { login email } }
95 query { viewer { login email } } GitHub
API
96 query { viewer { login email } } GitHub
API
96 query { viewer { login email } } GitHub
API GraphQL Query Analytics
97 query { viewer { login email } } GraphQL
Query Analytics Type: Query Field: viewer App: xxx Type: User Field: login App: xxx ...
98 Type: Query Field: viewer App: xxx Type: User Field:
login App: xxx ...
99 Type: Query Field: viewer App: xxx Type: User Field:
login App: xxx ...
100
101
GraphQL Schema Design @ Scale 102
Talk to, (or become) domain experts 103
Think Domain over Data 104
Sometimes it's not about "One Size Fits All" 105
Use the schema to build (or use) great tools! 106
Marc-Andre Giroux @___xuorig___ GraphQL Summit - Nov 7th 2018 Thank
You!