An Introduction To GraphQL
A quick overview to get you started
Grabbing data from an API endpoint can be simple if you only need a couple of bits from it. But it can get complex quickly, so if you want to try and organize things, GraphQL might be something you’ve started looking into.
The Problems with traditional REST APIs
JSONPlaceholder is an API where you can fetch fake data. From their /users endpoint, you can simply grab the name of a user and their email. What about when you find a more complex API, and need more than just a couple of values? There would be a lot more data, a lot more endpoints, and therefore a lot more requests to make!
Multiple requests in action
An example of this is if we were to fetch data from an API that has information on books. If you were to pass in the name of the book in an endpoint example.com/api/books/:title, you would receive data about that book, such as the bookId, authorId, genre, and blurb.
If you wanted to get information about the author, you would have to make another request that inputs the author’s id in the endpoint example.com/api/authors/:authorId. You would get the information you need, but this takes two requests to achieve, which is tedious and, given a lot more requests than this, can be hard to follow or understand. This is where GraphQL shines!
What is GraphQL?
GraphQL is a query language for API’s developed by Facebook. It allows developers to create more understandable API’s, and makes fetching data from them easier. It’s also a server-side runtime for executing queries. For those that would like to describe the type of data they should get back, GraphQL uses typing to do so as well! Using the book API example, this is how it would look:
What are the benefits of using GraphQL?
Did you notice in the code snippet above, we are passing in the author’s id? That’s because with GraphQL, we can request as much data as we need in one query! Given the authorId that we get back from that book, we can pass it in our query and also get the data from it. If the author had yet another set of id’s, we could get the data from those as well! The beauty of GraphQL is that it’s easy to send a query all in one go, which can be easier to read and understand.
We can also be selective with the data we get back. If we didn’t need the blurb property nor the age property from the API, we can simply omit it. The new query would look something like this:
This specificity allows developers to be more flexible with their requests, and also saves space for data that they actually need.
One method, one endpoint
If you are using GraphQL for your own database, it can serve as a way to worry less about endpoints. Often times you’ll be dealing with different requests, such as GET, POST, PUT, and DELETE. These all mean multiple requests do different things, but with GraphQL, your query is sent to one endpoint, POST /graphql. There are helper functions In that endpoint called “resolvers” that can act on whatever it is you need to do with the data in your query.
Planning out database endpoints can be a chore, especially if your app scales largely. Using GraphQL can make it a lot easier to get the data you need without worrying about path collisions or making your endpoints longer than they need to be.
GraphQL is a helpful tool for making data requests a lot easier, and a lot more understandable. The fact that it can be used across many languages means that you can use it for a lot of projects that have different tech stacks. Take more control with the data you request, and give GraphQL a try!
