Why GraphQL?

GraphQL

Origin

GraphQL was internally developed by Facebook in 2012 and was later open sourced in 2015. The idea emerged while Facebook decided to rebuild its mobile native applications. They were looking a powerful data-fetching API to describe all of Facebook’s data requirements yet simple enough to learn and adopt by their product developers and so they came up from this idea of declarative API implementation to a query language to a complete standardized GraphQL specification. Today it powers billions of API requests and is widely adapted by many big tech giants like Netflix, GitHub in their production applications.

REST and its shortcomings

REST(REpresentational State Transfer) has become one of the widely adopted, dominant software/API architectural style. The key abstraction that REST-compliant systems, often called RESTful systems are based on is resource. Any piece of information that can be identified and can be named is a resource. for eg: a document, an image, user data, etc. Since REST is resource oriented it uses a resource identifier(URI address) to identify that particular resource involved in the interaction(accessing, modifying) with the system. The resources are acted upon by using a set of simple, well-defined operations using URI(Unique Resource Identifier). The client and server exchange these resource representation by using a standard interface and protocol(HTTP) and identified by URI.

  • to a blog identified by id 27: /blogs/27
  • POST /blog : create a blog
  • PUT /blogs/27 : update blog identified by id 27
  • DELETE /blogs/27 : delete blog identified by id 27
query FetchUserBlogsAndCommentsQuery {
user(id: "123"){
id
username
email
blogs{
title
description
tags
comments{
author{
username
}
text
}
}
}
}
{
"data":{
"user":{
"id": 123,
"username": "John Doe",
"email": "john@doe.com",
"blogs":[
{
"title": "Why GraphQL??",
"description": "GraphQL was developed to cope with the need for more flexibility!",
"tags": ["GraphQL", "REST", "API"],
"comments":[
{
"author": {
"username": "Jane Doe"
}
"text": "This blog clearly explains why GraphQL was needed, Helped a lot!!"
}
]
}
]
}
}
}

Smaller precise payloads

One of the most common problems with REST is that of Over/under fetching of data which also results to filtering out un-necessary data. This mainly happens because the only way to for a client to query data is to hit multiple endpoints that return fixed shape of data. It is very difficult to design an API that adopts or provide precisely the data required by the client. GraphQL queries always return predictable results. Applications using GraphQL are fast and more stable because they control the data they get.

Over-fetching leads to downloading more data

Over-fetching means the client downloads more data than what was actually required in the application. As described in the above example if we hit /users/id endpoint to get only the id, username and email; It would result in returning all the other data as DOB, address, location etc. belonged to the user that were in-fact not necessary. over fetching leads to larger network payload and hence more load times.

Under-fetching for n+1 problem

Another issue is of under fetching which means that the endpoint we hit to get the data doesn’t provide enough of what we actually required for our application. Situations like these result in N+1 problem where a client has to make another request to another endpoint to fetch to gather the data it needs. As mentioned above in the blog list scenario we first have to fetch the user details the with that query the blogs endpoint and for every blog in the list that is returned make additional request to get all the comments for their respective blogs with proper username(comment author details) i.e. for each blog make request to /blogs/id/comments endpoint.

Benefits of a Schema and Strictly Type System

GraphQL uses a strictly, strong type system, All the types, shape of the data that are exposed in an API are defined by the schema using GraphQL schema definition language(SDL). This schema serves as the strong contract for what the operations look like and to determine if the query is valid. with this the schema not only defines the resources available for retrieval but also defines the accepted parameters when fetching the data. GraphQL APIs are organized in terms of types and fields, not endpoints. Thus clients can only ask for what is possible to return.

Documentation

Documentation is a first-class feature of a GraphQL system. It is important to ensure that services remain consistent, with its capabilities and so description of GraphQL definition are provided along side the definition in their definitions and are made available via introspection making it highly readable. This is a pretty powerful capability that allows service designers to easily describe and publish their documentation along side their implementations.

No more versioned APIs

Evolving a REST API is a challenge in itself, with newer implementations the endpoints have to be swapped, As the deployed clients cannot break and with rapid release cycles and backward compatibility guarantees, applications will have large number of API implementation versions, under such constraints it is difficult to remove data from custom endpoint. So much like REST the payloads of these custom endpoints grow monotonically as server evolves.

Better performance and rapid frontend iteration

A common practice with REST API is to structure the endpoints according to the frontend views. This comes handy since it allows clients to get all the data required for a particular view by simply accessing its corresponding endpoint. However, there is also a major drawback with this approach; it doesn’t allow evolving of views and rapid iteration of the frontends. with every change we make to our views we face with the risk that now there is more or less data than before and so adoptability to the evolving UI becomes quite difficult. The backend needs to adopt as well as account to the newer data needs. This kills down productivity of development and with over/under fetching it notably slows down the performance.

REST is GOOD GraphQL is BETTER

It’s not that REST is completely bad and is gonna die sooner, its just that REST is an architectural style rather than a formal protocol, There are actually much of a debate about what exactly REST is and what not it is. With GraphQL we represent a novel way of structuring the client-server contract. Sever publishes an application specific type system, GraphQL provides a unified language to query the data within specified constraints of type system. That language allows developers to express their precise data requirements in a declarative and hierarchal form. REST may long-live.

Get in touch

Hey, have any suggestions, questions or concerns, Feel free Mail me. You can also find me Twitter, GitHub and LinkedIn. Help me make this better drop me a message and I’ll get back to you soon Thanks!🎉

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Jay Gurav

Jay Gurav

5 Followers

Software Engineer, Front-end and Back-end developer, with interest in building scalable, highly efficient, resilient and user-friendly systems.