What I learned about GraphQL in one talk

GraphQL has been a buzzword for ages, and one that I’ve not had the time to really look into. Though, I’ve been at Codemotion Berlin this week 🎉, so when I saw Michelle Garrett’s talk ‘Build the API you want to see in the world (with GraphQL)’, it sounded like an opportunity to finally understand the hype.

Firstly, the thing that I’ve heard the most; is how GraphQL will eventually replace REST. Michelle started by talking about the differences between the two.

REST generally involves calls to different endpoints, like /movies /reviews or /actors then you have to figure out how to stitch these calls together to get the information you actually want. Makes sense, I’ve done this on a bunch of personal projects that use public APIs.

GraphQL on the other hand has one endpoint e.g. /graphql and all of your requests go to that endpoint. You also specify all the fields you want returned in your response and you will get exactly that. “No more, no less”, just what you ask for.

What GraphQL looks like to me from this talk, is a layer that sits between your API and your application, like some funky front-end middleware.

What the GraphQL setup looks like in my head

Interesting so far, but what are the real selling points? Why do people love it so much?

1. Some 3rd party APIs send you back a whole bunch of data you never need to use. As I mentioned earlier GraphQL doesn’t let this happen as you need to ask for every field you need.
2. Interestingly GraphQL seems to be more a tool for developer happiness. It still goes off and makes all the requests you would have done by hand, but as a developer you don’t have to think about the complexities involved in that. Specifically gluing different API responses together, like when you have to get the information from one response, and then you use that information to get a second response.
3. The set up at Condé Nast is self-documenting. Who doesn’t want documentation that never goes out of date?
4. Helps to enforce structure in your codebase, I didn’t get the details on this one but it sounds like when they adopted it at Condé Nast they saw improvement in this area.

Okies, I think I’m sold. When is the right time for me to use it?

1. If you have one set of data that needs to serve multiple applications. Michelle gave the example of having an API that you may use for a web application and an iOS app. Both of these will need to do similar logic to get the data they want into the right format. Having a GraphQL layer means this logic only has to be done once for all consumers.
2. If you need to combine data from different places and API endpoints, you can instead use GraphQL to “smoosh” it all together 😄
3. If you have some legacy API that has a bad interface, you could instead use GraphQL as a wrapper and make it nicer to use!
4. For the bantz 👀

Slide from Michelle’s talk at Codemotion Berlin 2018

Overall, GraphQL seems really cool! The only thing I don’t know yet, is how easy it is to set up your GraphQL layer in the first place 🤔 That can be some homework for me, when I find a project to squeeze it in to! 😄

Thanks Michelle for the great talk!