Introduction

When Facebook releases something, you gotta pay attention to it.

Not just because it's Facebook but because they are more often than not involved in projects at scale and the existing tech stack might have had suffered in those cases or would be missing altogether, which ultimately leads them (or any other big company for that matter) to create some good tech.

Take React, Osquery or GraphQL for example. All of them originated out of Facebook because they saw a gap or room for improvement and thus churned the hours to come up with these great tools and frameworks for us!

This post would act as a short primer on GraphQL. More specifically we will discuss about the what and why of GraphQL.

I have picked this topic up because I am sure if you are into development or pentesting, you must have heard about GraphQL. It's becoming quite popular and that's why you gotta pay attention to it, so that your skills stay industry-relevant.

Sounds interesting? Let's dive in.

What is GraphQL?

It is a data fetching and manipulation language that allows the clients to describe their data requirements with a JSON-like format.

A sample request would look like this:

Here we are getting the name and the age of the last 2 person records. Self-explanatory isn't it :)

And that's why its quite popular too — it's flexibility and the ability to control the data that the API returns makes it much more powerful.

Why GraphQL?

What's more powerful is that the shape of the response is same as the shape of the request. And that's what the following image depicts:

Notice that only the name of the hero is retrieved. Also, the response contains the field names that match up with the requested fields.

This makes the GraphQL APIs much more predictable. You know what the backend is going to send back, since you requested it.

Wait! There's more…

Also, notice that the fields that are being retrieved. In the backend, all these fields would get resolved via the resolver functions and then you would get back the response you wanted.

And thus, GraphQL aims to invert the control over the data, giving control to the API consumer instead of working with rigid server-defined endpoints, you can send queries to get exactly the data you're looking for in one request. You could thus say, it is an API-consumer-centric approach.

In essence, GraphQL is a better RESTful API comparable to RPC-style systems, that is, you get the best of all worlds, in one package!

Do I even need to use GraphQL?

It depends. (Taking a safer side since the answer depends on your use case).

Now look at these questions:

• Is your frontend data needs changing frequently due to rapid development, resulting in frequent backend code updation?
• Are your APIs returning back more data than any of the client consumers would want, leading to excessive data exposure issues and consuming more bandwidth too.
• Is the population of your views requires more APIs calls to fetch all the data instead of a single API call?
• Do you find it hard to maintain the different API endpoints in the REST APIs and instead want the flexibility of having a single endpoint that serves all your data need?
• Do you think that you already have planned a schema and want to enforce it, rather than updating your backend code based on frontend client needs as the data requirements change?

If you think one or more of the above points sounds relatable, then yes you should use GraphQL. Otherwise, it's totally up to you. Feel free to try it out and tinker around just for funzies.

Closing Thoughts

I suppose this post was able to answer all of your questions on What GraphQL is and Why should you use it and also I hope that now you would better be able to judge if you need to use GraphQL or not.

If this post makes you more curious and interested in GraphQL, let me know in the comments below and I will eventually write about some of my GraphQL pentesting experiences in my upcoming posts.

With that, I close off this post. Until the next one, keep learning and happy hacking!