Demystify GraphQL

Table of contents

Reading Time: 4 minutes

In this blog, I will be introducing and demystify the GraphQL. I will be elaborating its advantages. And also put some focus on its inception and reasons for its popularity.

GraphQL is both a query engine and a query language. It was first created by Facebook in 2012. Initially, the design was more of a specification. Facebook used it as a specification to describe the capabilities and requirements of data models for client-server applications. So they thought of making it an open standard.

Introduction

GraphQL is query language of API’s. Communication with a server using it is very close to the natural responses that we build by making combining several responses from the server in case of REST APIs.

Another thing, the graph in the name does not link it to Graph Database. It is only an indication of the characteristic of crawling over the APIs that is provided by it.

Why GraphQL?

Client applications build using the GraphQL are provided with a very intuitive and flexible syntax for describing their data requirements and interactions. Confused? Let me put it this way, rather than the client depending on the server supported queries and getting a fixed response and then filtering and modelling it, the client can specify its own queries.

Data Requirements Client Side vs Server Side

Let us quickly see the formal definition

It is a query language for your API, and a server-side run-time for executing queries by using a type system you define for your data. The query language does not tie specific databases or storage engines with it. It is backed by the existing code and data.

GraphQL service

The service has to define types and fields on those created types, then provide functions for each field on each type. Clients use the GraphQL query language to make requests to the service. The requests are referred to as documents. A document may contain operations (queries, mutations, and subscriptions).

For example, a service that tells us who the logged in user is (loggedIn) as well as that user’s name might look something like this:

type Query {
  loggedIn: User
}

type User {
  id: ID
  name: String
}

Lets go a step further and define functions for each field

function Query_loggedIn(request) {
  return request.auth.user;
}

function User_name(user) {
  return user.getName();
}

Now once we have the service running, we can fire the queries to validate and execute. So whenever the server gets a query it does the following :

validation for the correctness of types and fields defined
executes the query to get the results

So let us see what we get on the following query

{
  loggedIn {
    name
  }
}

the response would look like

{
  "loggedIn": {
    "name": "Guest-1"
  }
}

So the next important thing here is that application servers take their capabilities and maps them to a uniform language and type system to support GraphQL.

GraphQL design Principles

The graphQL is based on a number of design principles. All these together make it a powerful and productive environment for building client applications.

Hierarchical: Most product development today involves the creation and manipulation of view hierarchies. To achieve congruence with the structure of these applications, the query itself is structured hierarchically. The query is shaped just like the data it returns. It is a natural way for clients to describe data requirements.

Product‐centric: It is un-apologetically driven by the requirements of views and the front‐end engineers that write them. It starts with their way of thinking and requirements and builds the language and run-time necessary to enable that.
Strong‐typing: Every server defines an application‐specific type system. Queries are executed within the context of that type of system. Given a query, tools can ensure that the query is both syntactically correct and valid within the type system before execution, i.e. at development time, and the server can make certain guarantees about the shape and nature of the response.
Client‐specified queries: Through its type system, a GraphQL server publishes the capabilities that its clients are allowed to consume. It is the client that is responsible for specifying exactly how it will consume those published capabilities. These queries are specified at field‐level granularity. In the majority of client‐server applications written without GraphQL, the server determines the data returned in its various scripted endpoints. A GraphQL query, on the other hand, returns exactly what a client asks for and no more.
Introspective: It is introspective. The server’s type system must be queryable by the query language itself, as will be described in this specification. The introspection serves as a powerful platform for building common tools and client software libraries.

GraphQL vs REST

The amount of data sent to the client makes the biggest difference. The Graphql is efficient enough, it sends what is exactly asked. Whereas REST sends everything to the client.

Let us see more differences in the table below: