
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!
5
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!
30,839 Listeners
284 Listeners
2,395 Listeners
3,926 Listeners
215 Listeners
331 Listeners
987 Listeners
7,879 Listeners
4,142 Listeners
192 Listeners
417 Listeners
47 Listeners
485 Listeners
13 Listeners
2 Listeners