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:

• Linode – Our cloud server of choice. Get one of the fastest, most efficient SSD cloud servers for only $5/mo. Use the code changelog2017 to get 4 months free!
• Hired – Get hired. It’s free — in fact, they pay you to get hired. Our listeners get a double hiring bonus of $600.
• GoCD – GoCD is an on-premise open source continuous delivery server created by ThoughtWorks that lets you automate and streamline your build-test-release cycle for reliable, continuous delivery of your product.
• Microsoft Azure OpenDev – See what’s possible with open source in the cloud. Watch the recorded videos from this live event to see real-world demonstrations of Azure supporting open technologies. Hear from leaders in the open source community. Learn how you can build containerized microservices and improve your open source DevOps pipeline.

Featuring:

• Johannes Schickling – Twitter, GitHub
• Adam Stacoviak – Mastodon, Twitter, GitHub, LinkedIn, Website
• Jerod Santo – Mastodon, Twitter, GitHub, LinkedIn

Show Notes:

• Learn GraphQL How to GraphQL
• Learn Apollo
• Learn Relay
• GraphQL Playground
• GraphQL.org
• Facebook’s announcement post for GraphQL
• Graphcool - Serverless GraphQL Backend - Developer platform for building serverless graphql backends
• Graphcool hit #1 on HackerNews when it launched
• GraphQL Radio - a podcast covering all things GraphQL
• GraphQL-Europe - Europe’s first GraphQL conference
• Reinventing Authorization: GraphQL Permission Queries
• Serverless GraphQL Backend architecture
• Why GraphQL is the future
• Facebook’s original draft RFC specification for GraphQL

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!