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
Launching GitHub's Public GraphQL API
Search
Sponsored
·
Your Podcast. Everywhere. Effortlessly.
Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
→
Brooks Swinnerton
May 21, 2017
Technology
570
2
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
Launching GitHub's Public GraphQL API
Brooks Swinnerton
May 21, 2017
More Decks by Brooks Swinnerton
See All by Brooks Swinnerton
Building GitHub Integrations with Webhooks and REST
bswinnerton
1
170
Launching GitHub's GraphQL API
bswinnerton
4
520
Optimizing APIs for Consumers with GraphQL
bswinnerton
2
450
GitHub GraphQL API
bswinnerton
4
150
GraphQL for Rubyists
bswinnerton
0
310
The Road To Code: Ruby
bswinnerton
0
110
The history of Vim
bswinnerton
0
150
Other Decks in Technology
See All in Technology
AIっぽい文章を採点して人間らしく直すアプリを作ってみた
yama3133
2
110
Agentic ERPをどう設計するか ー 受発注エージェントを動かす、現場の知見と設計思想ー
recerqainc
1
2.1k
2026TECHFRESH畢業分享會 - 原生還是跨平台? App 開發踩坑實錄
line_developers_tw
PRO
0
550
ブロックチェーン / Blockchain
ks91
PRO
0
120
就職⽀援サービスにおけるキャリアアドバイザーのシフトスケジューリング
recruitengineers
PRO
1
120
Socrates × Looker 〜セマンティックレイヤーで進化するデータ分析エージェント〜
hanon52_
3
1.9k
Disciplined Vibes: Scaling AI-Assisted Engineering
sheharyar
0
110
「速く作る」から「正しく作る」へ ─ 生成AI時代の開発フロー改革の ロードマップと実行 ─
starfish719
0
9.5k
Microsoft Build Keynoteふりかえり
tomokusaba
0
120
タクシーアプリ『GO』の実践的データ活用
mot_techtalk
3
190
ChatworkとBPaaS 異なる特性で学んだAI機能開発の ベストプラクティス
kubell_hr
2
3.4k
OCI Oracle AI Database Services新機能アップデート(2026/03-2026/05)
oracle4engineer
PRO
0
330
Featured
See All Featured
The Art of Programming - Codeland 2020
erikaheidi
57
14k
Darren the Foodie - Storyboard
khoart
PRO
3
3.4k
The State of eCommerce SEO: How to Win in Today's Products SERPs - #SEOweek
aleyda
2
11k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
PRO
201
75k
Bioeconomy Workshop: Dr. Julius Ecuru, Opportunities for a Bioeconomy in West Africa
akademiya2063
PRO
1
140
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
12
1.7k
16th Malabo Montpellier Forum Presentation
akademiya2063
PRO
0
140
B2B Lead Gen: Tactics, Traps & Triumph
marketingsoph
0
140
Designing for humans not robots
tammielis
254
26k
The innovator’s Mindset - Leading Through an Era of Exponential Change - McGill University 2025
jdejongh
PRO
1
200
Mozcon NYC 2025: Stop Losing SEO Traffic
samtorres
1
250
Primal Persuasion: How to Engage the Brain for Learning That Lasts
tmiket
0
360
Transcript
+ a
Hi, I’m Brooks
I work at !
let’s talk about launching the GitHub GraphQL API
How our GraphQL API came to be
March 20th, 2016 proposal submitted
we had dreams of APIv4
multiple resources in one roundtrip
schema introspection
April 6th, 2016 proof of concept done
{ current_user { login repositories(affiliation: "owner") { id name }
} }
April 12th, 2016 New team created
September 14th, 2016 early access
Today >100 million queries/day
We learned some things along the way
Tooling
documentation
https://github.com/gjtorikian/graphql-docs
GraphiQL all-in-one
"but we’re going to need a Ruby client"
github/graphql-client
objects in exchange for a query
collocate our queries with our views
but in Rails
query profiling
query { repository(owner:"rails", name:"rails") { viewerHasStarred } }
{ "data": { "repository": { "viewerHasStarred": false } }, "extensions":
{ "totalDuration": 42.06737782806158, "trackedAssociations": {}, "profiling": { "Repository:viewerHasStarred": { "type": "Boolean!", "sql": [ { "duration": 2.07, "sql": "SELECT 1 AS one FROM `repositories` INNER JOIN `stars` ON `repositories`.`id` = `stars`.`starrable_id` WHERE `stars`.`user_id` = 934497 AND `stars`.`starrable_type` = 'Repository' AND `repositories`.`id` = 8514 LIMIT 1 " } ] } } } }
Authorization
reusing the OAuth logic from our REST API
OAuth scopes are granted to a token
token is used to make a request
familiar to our users
less for us to build
Organization = GraphQL::ObjectType.define do name "Organization" accepted_scopes ["read:org", "admin:org"] end
Organization = GraphQL::ObjectType.define do name "Organization" accepted_scopes ["read:org", "admin:org"] end
but with ✨ GraphQL ✨…
we can analyze the query before resolution
query { organization(login:"github") { members { totalCount } } }
query { organization(login:"github") { members { totalCount } } }
Organization = GraphQL::ObjectType.define do name "Organization" accepted_scopes ["read:org", "admin:org"] end
but this isn’t perfect
in some cases you need to perform resolution first
repo vs public_repo
we’ve introduced an authz layer for resolution
Schema design
first off
there’s more than one
one for new & sensitive features
one for everyone else
Organization = GraphQL::ObjectType.define do name "Organization" accepted_scopes ["read:org"] end
Organization = GraphQL::ObjectType.define do name "Organization" accepted_scopes ["read:org"] visibility :public
end
Organization = GraphQL::ObjectType.define do name "Organization" accepted_scopes ["read:org"] visibility :public
end
CoolNewFeature = GraphQL::ObjectType.define do name "CoolNewFeature" accepted_scopes ["repo"] visibility :internal
end
mandatory first/last arguments on connections
query { viewer { repositories(last:30) { edges { node {
name } } } } }
query { viewer { repositories(last:30) { edges { node {
name } } } } }
is/has/can prefix
query { repository(owner:"rails", name:"rails") { isFork hasIssuesEnabled viewerCanAdminister } }
query { repository(owner:"rails", name:"rails") { isFork hasIssuesEnabled viewerCanAdminister } }
avoiding fields that should be types
query { repository(owner:"rails", name:"rails") { ownerLogin } }
query { repository(owner:"rails", name:"rails") { ownerLogin } }
query { repository(owner:"rails",name:"rails") { owner { login } } }
Feature Parity
schema driven development* *stay tuned!
with our REST API
new features were developed for the UI
then staff-shipped
then released
REST API work started after the ship
but, today…
all new features are built with GraphQL
from the start
CoolNewFeature = GraphQL::ObjectType.define do name "CoolNewFeature" accepted_scopes ["repo"] visibility :internal
end
CoolNewFeature = GraphQL::ObjectType.define do name "CoolNewFeature" accepted_scopes ["repo"] visibility :internal
end
CoolNewFeature = GraphQL::ObjectType.define do name "CoolNewFeature" accepted_scopes ["repo"] visibility :public
end
this allows us to build a true public API
this allows us to build a true public API
this allows us to build a true platform
shared between GitHubbers and integrators
but change is scary
GraphQL-backed REST APIs
this works great for new features
but what about legacy features?
GET https://api.github.com/user
enter Scientist
github/scientist
measure data discrepancies
measure the difference in performance
None
Where we’re headed
static analysis of schema during code review
rate limiting
expose global relay IDs in REST API
preview new fields and objects with headers
Thank you @bswinnerton on Twitter & GitHub @brooks on Slack