I’ve been asked about Graphql in my recent interview. To be honest, I didn't know about it before. As my mind would likely jump to REST when I need to build an API. After the interview, I did some research on Graphql and decide to write a post about it. While this post only dipped the toes into the ocean that is GraphQL, it would serve as a good place to learn and start using GraphQL in my future project.

WHAT IS GRAPHQL?

GraphQL is a query language and a set of tools that use HTTP to work on single endpoints in order to optimize flexibility and performance. In GraphQL, data is organized into a graph, and objects are structured by nodes following a schema.

WHY WAS GRAPHQL CREATED IF THERE IS ALREADY REST?

Graphql was created due to the boom in mobile usage, which led to some issues with low-powered devices and sloppy networks. REST isn’t optimal to deal with those problems. Also, the number of different front-end frameworks and platforms that run client applications increase as well. Given REST’s inflexibility, it was harder to develop a single API that could fit the requirements of every client. If we go even further, we realize that the main reason why an alternative solution was identified was that most of the data used in modern web and mobile applications have a graph shape.

WHAT ARE THE PROBLEMS THAT GRAPHQL SOLVES COMPARING WHEN USING REST API?

Before we dive into this question. Let’s me give you a Simple GraphQL example, Imagine that you have a blog, and you want to query all the post data, you can simply do so by writing a query as below:

query {
  posts {
    title
    subtitle
    date
    author {
      name
    }
  }
}

Json Rsponse we will get from it:

[
  {
    "title": "Cooler post",
    "subtitle": "...",
    "date": "07/05/2019"
  },
  {
    "title": "Cool post",
    "subtitle": "...",
    "date": "06/05/2019"
  }
]

As you can see, GraphQL’s declarative nature makes it incredibly easy to understand what is going on at all times, as we are basically writing JSON objects without the values.

However, full power comes when you want more. For example, what if you want to see the author as well? With rest API, You have three options to achieve this:

1. Fetch the authors from another resource

GET /api/post/:id

{
  "post": {
    ...,
    "author": {
      "name": "Dio Brando"
    }
  }
}

This approach can be categories as under fetching. you will end up with two server requests instead of one, and as you continue to scale, you may have even more requests to different endpoints in order to fetch all the needed data.

2. Modify the resource to also return the author

GET /api/posts

[
  {
    ...,
    "author": {
      "name": "Dio Brando"
    }
  },
  {
    ...,
    "author": {
      "name": "Johnathan Joestar"
    }
  }
]

This approach causes over-fetching. Since you modified the resource, now it also shows the author with it everywhere. Even at the places, you don't need author data.

3. Create a new resource that returns the posts with the author

GET /api/postsWithAuthor

[
  {
    ...,
    "author": {
      "name": "Dio Brando"
    }
  },
  {
    ...,
    "author": {
      "name": "Johnathan Joestar"
    }
  }
]

This approach may solve problems such as the one described above, it also slows down the front-end development, since each specific view needs its specific endpoint. If at any point a view needs new data, the development has to slow down until the endpoint is updated.

Since GraphQL allows the client to only fetch the needed data, this problem would not exist!!

IT SOUNDS PRETTY AMAZING… SO … WHAT IS THE CATCH?

There are still some missing elements to make it perfect. If you aim to have one of the next points in your project, you should consider the usage of REST.

Non-existent HTTP caching mechanism

1. Non -existent HTTP caching mechanism. When using GraphQL there is no way to get a globally unique identifier for a given object because we use the same URL for all the requests.
2. When using REST you can build a monitoring system based on API responses. On GraphQL you don’t have that, because it always returns 200 OK status response.
3. with GraphQL you can query exactly what you want whenever you want, but we should be aware that this leads to complex security implications. you will be vulnerable to DDoS (Denial-of-service attack) attacks.

Wrap up

GraphQL provides a smooth and fast development environment with its declarative and flexible nature, offering many improvements over REST. If you are aiming to develop an API to be used on a mobile application you should have GraphQL as the first option because bandwidth usage matters. If your application requires a robust API, with caching and a monitoring system you should go with REST.