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
79
So you Want to Distribute your GraphQL Schema?
xuorig
4
780
So you Want to Distribute your GraphQL Schema?
xuorig
0
460
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
320
From REST to GraphQL
xuorig
9
1.2k
Other Decks in Programming
See All in Programming
Compose Multiplatform과 Ktor로 플랫폼의 경계를 넘어보자
kwakeuijin
0
220
自分だけの世界を創るクリエイティブコーディング / Creative Coding: Creating Your Own World
chobishiba
2
270
PHPを書く理由、PHPを書いていて良い理由 / Reasons to write PHP and why it is good to write PHP
seike460
PRO
5
280
Cloud Adoption Framework にみる組織とクラウド導入戦略
tomokusaba
2
160
データサイエンスのフルサイクル開発を実現する機械学習パイプライン
xcnkx
2
460
Taking LLMs out of the black box: A practical guide to human-in-the-loop distillation
inesmontani
PRO
3
1.1k
ACES Meet におけるリリース作業改善の取り組み
fukucheee
0
120
為醫療加裝Python的引擎
cclai999
0
270
ECS向けのドリフト検知機構を実装してみた
tkikuc
0
270
ビット演算の話 / Let's play with bit operations
kaityo256
PRO
4
160
グローバルなソフトウェアテスト組織における課題と戦略 / Challenges and Strategies in a Global Software Testing Organization #mf_techday
imtnd
0
230
Removing Corepack
yosuke_furukawa
PRO
9
1.1k
Featured
See All Featured
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
25
640
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
26
4k
Designing the Hi-DPI Web
ddemaree
279
34k
Visualization
eitanlees
143
15k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
279
13k
The World Runs on Bad Software
bkeepers
PRO
65
11k
WebSockets: Embracing the real-time Web
robhawkes
59
7.3k
The Power of CSS Pseudo Elements
geoffreycrofte
71
5.3k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
6
230
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
4
99
Building Flexible Design Systems
yeseniaperezcruz
327
38k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
45
4.9k
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!