Today in IBM Hursley I gave a quick introduction to GraphQL. We are using GraphQL in my current project at IBM Watson, with good success. While we as a team are still learning how to best use it, I can at least attest for its benefits compared to REST.

REST is not without issues, baked into its design. By describing only how to seek and modify data, servers and clients can be tightly coupled, which means it can be difficult to apply change to the API without causing a lot of work to update the client.

Another issue with REST is predicting what a client will request. Designing an API usually means designing how the client will need and utilise the data. If the client strays off the beaten path, it can result in underfetching an overfetching, meaning requiring additional API calls for more data, and discarding useless fields in payloads.

GraphQL aims to beat these issues, and more. By describing your data structures in a strongly typed schema, you define, and implement with resolvers, only the data itself. This means you aren’t enforcing a way of fetching data on your client, only providing whatever the client asks for.

The client then queries the graph of data, fetching all and only what it needs, saving time and bandwidth, in a single payload.

For more information, I recommend the GraphQL website and How to GraphQL.

Alternatively, read my slides that follow.