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
84
So you Want to Distribute your GraphQL Schema?
xuorig
4
790
So you Want to Distribute your GraphQL Schema?
xuorig
0
480
Continuous Evolution of GraphQL Schemas @ GitHub
xuorig
3
2k
GraphQL à Shopify
xuorig
0
210
Exploring GraphQL
xuorig
0
250
GraphQL @ Shopify
xuorig
6
1.5k
GraphQL on Rails
xuorig
2
330
From REST to GraphQL
xuorig
9
1.2k
Other Decks in Programming
See All in Programming
StarlingMonkeyを触ってみた話 - 2024冬
syumai
3
270
Mermaid x AST x 生成AI = コードとドキュメントの完全同期への道
shibuyamizuho
0
160
今年のアップデートで振り返るCDKセキュリティのシフトレフト/2024-cdk-security-shift-left
tomoki10
0
200
Scalaから始めるOpenFeature入門 / Scalaわいわい勉強会 #4
arthur1
1
330
コンテナをたくさん詰め込んだシステムとランタイムの変化
makihiro
1
130
創造的活動から切り拓く新たなキャリア 好きから始めてみる夜勤オペレーターからSREへの転身
yjszk
1
130
バグを見つけた?それAppleに直してもらおう!
uetyo
0
180
Stackless и stackful? Корутины и асинхронность в Go
lamodatech
0
760
range over funcの使い道と非同期N+1リゾルバーの夢 / about a range over func
mackee
0
110
Cloudflare MCP ServerでClaude Desktop からWeb APIを構築
kutakutat
1
550
良いユニットテストを書こう
mototakatsu
8
2.4k
テスト自動化失敗から再挑戦しチームにオーナーシップを委譲した話/STAC2024 macho
ma_cho29
1
1.3k
Featured
See All Featured
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
507
140k
Building Your Own Lightsaber
phodgson
103
6.1k
Into the Great Unknown - MozCon
thekraken
33
1.5k
Making the Leap to Tech Lead
cromwellryan
133
9k
Bash Introduction
62gerente
608
210k
GraphQLの誤解/rethinking-graphql
sonatard
67
10k
For a Future-Friendly Web
brad_frost
175
9.4k
No one is an island. Learnings from fostering a developers community.
thoeni
19
3k
YesSQL, Process and Tooling at Scale
rocio
169
14k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
159
15k
Java REST API Framework Comparison - PWX 2021
mraible
28
8.3k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
247
1.3M
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!