
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 Media5
55 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!

289 Listeners

26,327 Listeners

622 Listeners

987 Listeners

210 Listeners

8,462 Listeners

207 Listeners

47 Listeners

9,927 Listeners

517 Listeners

29,188 Listeners

2,226 Listeners

62 Listeners

14 Listeners

26 Listeners