GraphQL gives us flexibility in receiving responses, i.e. a client consuming the GraphQL API can demand what is required. Imagine an application for listing todo lists, containing fields like title, body, status, completedAt, createdAt, and updatedAt. The REST API implementation sends all these fields. In the frontend design, the todo lists are shown initially using a title and status i.e. only 2 fields title and status are required for the listing design. Here the complete response of the API like createdAt, updatedAt, body is unused, which will increase the response size and increases the response time received at the client-side. Another approach is to design multiple API endpoints for sending different responses as required by the design. This implementation is very costly and requires high maintenance, as the implementation needs to be updated whenever the UI design changes.

This is where GraphQL API shines in, the client can query only those fields which are required at the particular design. By doing this the response time and size can be minimized. In the future, any changes to the UI design can be made easily by simply modifying the request query.

Example:

A REST API endpoint for fetching todo lists:

Get http://somedomain.com/todo/lists

Response Body:

{
 “data”: [
 {
 “title”: “Todo list I”,
 “status”: true,
 “body”: “Todo list I Description.”,
 “createdAt”: “2020–05–06”,
 “updatedAt”: “2020–05–06”
 },
 {
 “title”: “Todo list II”,
 “status”: false,
 “body”: “Todo list II Description.”,
 “createdAt”: “2020–05–06”,
 “updatedAt”: “2020–05–06”
 }
 ]
}

Similarly, for GraphQL, a request is sent to an URL:
POST: http://somedomain.com/graphql
the same can be achieved by using the following query:

query todos {
 todos {
   title
   status
   body
   createdAt
   updatedAt
 }
} 

The response received from the above query will be the same as above. However what if the client-side only utilizes the title, status and body then the timestamps are useless and increase the response size. This can be achieved by the below query i.e. just remove the createdAt and updatedAt.

query todos {
 todos {
   title
   status
   body
 }
}

Now the response will look something like the below:

{
 “data”: [
 {
 “title”: “Todo list I”,
 “status”: true,
 “body”: “Todo list I Description.”
 }
 {
 “title”: “Todo list II”,
 “status”: false,
 “body”: “Todo list II Description.”
 }
 ]
}

Advantages:
It decreases the need for multiple API endpoints. It also decreases multiple requests to the backend for fetching various data. E.g. in a REST API fetching posts, categories and comments require 3 endpoints to be called, while in GraphQL These all can be called in a single request from the backend as follows:

## If the posts, categories and comments are related with each other, we can fetch them as a graph.
query blog {
 posts {
   title
   status
   body
   comments {
    body
    name
   }
   category {
    name
   }
 }
}## If the posts, categories and comments are not related with each other.
query blog {
 posts {
   title
   status
   body
 }
  comments {
   body
   name
  }
  category {
   name
  }
}

Conclusion:
GraphQL is not a replacement for REST API, however, it can be used to optimize the response time and response size from the server. GraphQL is rapidly being adopted by many organizations.