Introduction to GraphQLGraphQL is a string query language which is used to retrieve information from server to the client in a specific format. It is a powerful tool for your APIs which enables you to fetch the data from multiple sources in a single query.

GraphQL was developed by Facebook. Instead of having multiple endpoints for the API, they decided to come up with a single query which will fetch all the requested details by a client and this led to the creation of GraphQL. GraphQL makes it easy to query and retrieve only those data that are required. It is also possible to read data from multiple data sources in a single query which makes GraphQL a preferred choice for many. For example, you can query data stored in MySQL server and also from Redis at the same point in a single query.

Here is an example of GraphQL

{

user(id: 3500401) {

id,

name,

isViewerFriend,

profilePicture(size: 50)  {

uri,

width,

height

}

}

}

This is the response from server for the above GraphQL query

{

“user” : {

“id”: 3500401,

“name”: “Jing Chen”,

“isViewerFriend”: true,

“profilePicture”: {

“uri”: “http://someurl.cdn/pic.jpg”,

“width”: 50,

“height”: 50

}

}

}

Key Concepts of GraphQL

Hierarchical

A large portion of products built today involves creation and management of hierarchical views. To facilitate this structure, GraphQL is also a hierarchical set of views. The string query is structured similar to the data that is requested. This is a simple and easy method for developers to request data from the server.

GraphQL

Product-centric

GraphQL is developed purely considering the requirements of front-end developers and their views. A developer can write the query by describing his exact requirements without worrying about the endpoints.

Client-specified queries

If you consider any other query language, it is purely based on the structure of data that is stored on the server and not the client request. The client has to write the query based on the existing server data structure using endpoints already mentioned. In GraphQL, queries are encoded purely by the client and not on the server which makes it easy for the client to retrieve only the data that he desires and nothing more.

Backwards Compatible

We live in a world where millions of native mobile apps are deployed without forced upgrades. Most of the popular apps are regularly updated but there is no guarantee that the client will update. For example, Facebook releases a new update every 2 weeks and offer a minimum 2 years maintenance for the same. So at any given time, there are 52 versions of the Facebook app being used by clients all over the world. Imagine 50+ client versions querying the Facebook server for data? The only way to offer backward compatibility is to ensure client specific queries and keeping the server flexible.

Structured, Arbitrary Code:

Most of the query languages rely on query storage engine like SQL. On the other hand GraphQL doesn’t rely on any engine, instead queries the server directly with a structure using arbitrary code. This ensures maximum flexibility of data from the server and also enables consistency of API across the platform.

Application-Layer Protocol

One of the biggest advantages of GraphQL is that it is an Application layer protocol. No separate third-party transport protocol is required. The structure string is parsed and read by the server directly.

Strongly-typed

GraphQL is a strongly typed language where high-quality client tools can ensure that the query is both syntactically correct and valid.

Also Read: Mobile App Frameworks

REST vs GraphQL

Before the onset of GraphQL, REST was the most widely used architecture for API. Data from the server in a REST system is typically requested using URIs and interfaced with terms. Some of the key REST verbs are HTTP GET, HTTP PUT AND HTTP DELETE. GET is to fetch data from a server in a server-specific format and PUT is used to write data back to the server. All the extra data that is required are fetched using end-points in the REST.

Disadvantages of REST

  • To read complex data structures requires multiple round trips between the client and server. This causes unnecessary delay mainly considering that most of the mobile applications operate in variable network speeds.
  • Additional data is fetched by using predefined end-points in REST API. This over time leads to data overload on the client. A REST API with endpoints fetches both the basic data and also the additional data. The client ends up getting what he requires and also the data that is not required. With GraphQL a client can request only the data he requires at that point of time.
  • REST endpoints are weakly-typed whereas GraphQL is a strongly typed one. A weakly typed query results in data which is not readable by machines and thus tooling is not possible. GraphQL, on the other hand, follows correctness and opens the door for tooling.