
Sign up to save your podcasts
Or


Johannes Schickling (Founder of Graphcool) joined the show to talk about GraphQL — an application layer query language from Facebook. We talked about what it is, where it makes sense to use it, its role in serverless architectures, getting docs for free via Schemas and Types, and the community that’s rallying around this new way to think about APIs.
Join the discussion
Changelog++ members support our work, get closer to the metal, and make the ads disappear. Join today!
Sponsors:
Featuring:
Show Notes:
From The GitHub GraphQL API post on the GitHub Engineering blog:
The REST API is responsible for over 60% of the requests made to our database tier. This is partly because, by its nature, hypermedia navigation requires a client to repeatedly communicate with a server so that it can get all the information it needs. Our responses were bloated and filled with all sorts of *_url hints in the JSON responses to help people continue to navigate through the API to get what they needed. Despite all the information we provided, we heard from integrators that our REST API also wasn’t very flexible. It sometimes required two or three separate calls to assemble a complete view of a resource. It seemed like our responses simultaneously sent too much data and didn’t include data that consumers needed.
Something missing or broken? PRs welcome!
By Changelog Media4.7
286286 ratings
Johannes Schickling (Founder of Graphcool) joined the show to talk about GraphQL — an application layer query language from Facebook. We talked about what it is, where it makes sense to use it, its role in serverless architectures, getting docs for free via Schemas and Types, and the community that’s rallying around this new way to think about APIs.
Join the discussion
Changelog++ members support our work, get closer to the metal, and make the ads disappear. Join today!
Sponsors:
Featuring:
Show Notes:
From The GitHub GraphQL API post on the GitHub Engineering blog:
The REST API is responsible for over 60% of the requests made to our database tier. This is partly because, by its nature, hypermedia navigation requires a client to repeatedly communicate with a server so that it can get all the information it needs. Our responses were bloated and filled with all sorts of *_url hints in the JSON responses to help people continue to navigate through the API to get what they needed. Despite all the information we provided, we heard from integrators that our REST API also wasn’t very flexible. It sometimes required two or three separate calls to assemble a complete view of a resource. It seemed like our responses simultaneously sent too much data and didn’t include data that consumers needed.
Something missing or broken? PRs welcome!

271 Listeners

623 Listeners

268 Listeners

585 Listeners

289 Listeners

146 Listeners

987 Listeners

210 Listeners

207 Listeners

205 Listeners

63 Listeners

141 Listeners

500 Listeners

40 Listeners

63 Listeners