Let’s learn 101 of GraphQL | Introduction |Part-1
GraphQL is a query language which can ask only the data that it needs. No need to worry about the server response, clients are able to control the data that they want. It is often referred to as a declarative data-fetching language. By that, we mean that developers will list their data requirements as what data they need without focusing on how they’re going to get it.
Let’s say suppose I want to show only First Name and Last Name in my UI, but that object contains First Name, Last Name, Address and lot of details, If we write it as REST API means, we can’t able to get only specific fields, it will return all the fields of the object. But in our case we are able to get only the first name and last name by using a single endpoint in GraphQL. That’s the beauty of GraphQL.
Whenever a query is executed against a graphQL server, it is validated against a type system. Every GraphQL service defines types in a graphql schema. You can think of a type system as a blueprint for your API’s data, backed by a list of objects that you define.
Origin Of GraphQL
In 2012, One of the leading tech giant facebook’s iOs and Android apps were just thin wrappers around the views of the mobile website, Facebook used a RESTful server and the performance was struggling and the apps often crashed. At that time, Facebook developers decided to develop something that will improve the way that data was being sent to the client applications. As a result graphQL is developed and came into production ready in 2015 to this tech world. Now most of the big heads like GitHub( One of the early adopters of GraphQL), IBM, Intuit etc., are using GraphQL in their production.
Limitations of REST
Over Fetching
Suppose you are building an student management application where faculties can add students and keep track of student information. So we have a REST API to add,get,delete,update students. Admin successfully created 100 students using the add student REST API. After that the admin wants to see all the student details. So in that application UI is like showing the students in the list manner which showing student name and year only, on click of particular student it will open a popup with brief information including student address, father details etc., So the REST API /get is called and it is defined to return the predefined object structure includes all information data for student. This is a clear case of overfetching — We’re getting a lot of data back that we don’t need. The UI we need only two fields (student name & year) only right, but we’re getting back an object with 12 keys and sending information over the network that is useless.
Under Fetching
Let’s say we get one more requirement from our admin to add another feature to our Student Management application. In addition to the student name and year, we now need to display the list of sports titles that student is in. After we request the data from https://examplerestapi.com/student/1, we still need to make additional requests for more data. This means we are under fetched. So to show a list of sports and clubs students associated with, we’d need to make a lot more requests. In this case, for example we need to hit 10 more routes and make 10 more round trips to the client.
Birth of Rescuer
Let’s add the importance of GraphQL with one more example,
You are working on X company, there in cafeteria you have a vending machine and so traditional REST is like you press one button and get one thing and then this problem happens where you press one button get one thing you have to press lots of button one at a time and that’s slow so what people do is they make a special-purpose buttons that like say like one button you get four things another button you get five things. Imagine if you press exactly the buttons you want and then get it in one shot but in combination with that, the idea is converted into the development of GraphQL.
GraphQL solved the major problem in REST — Over Fetching & Under Fetching by issuing GraphQL Query. Here On the left, we issue a GraphQL query with only the fields that we want. On the right, we receive a JSON response but this time containing only the data that we requested, not extra fields that are required to travel from a database to a browser for no reason at all. To be simple, we ask for data in a certain shape, we receive the data back in that shape. Nothing more, nothing less ! To solve under fetching, GraphQL solution is to define a nested query and then request the all necessary data in one fetch.
In the case of REST it is purely URL-Driven, to get the multiple data we need to make multiple calls to multiple different endpoints, but the beauty of the GraphQL, query driven language is having single endpoint but always POST, to get all kind of data in single shot or calling the same point with different set of data request as per the client needs. REST response is predefined by the server whereas GraphQL response is purely defined by the client. So the minimal needed data only will be get loaded by the browser.
Guidelines on GraphQL Specifications
Even though GraphQL is not controlling about how you build your API, it does offer some guidelines for how to think about a service.
- Hierarchical
A graphQL query is hierarchical. Fields are nested within other fields and the query is shaped like the data that it returns.
- Product Centric
GraphQL is driven by data needs of the client and the language and runtime that supports the client.
- Strong Typing
A graphQL server is backed by the GraphQL type system. In the Schema, each data point has a specific type against which it will be validated.
- Client-Specified queries
A GraphQL server provides the capabilities that the clients are allowed to consume.
- Introspective
The GraphQL language is able to query the GraphQL server’s type system.
3 Idiots of GraphQL 😄
As like DDL, DML commands, We have three types in GraphQL,
- Query — To retrieve the data
- Mutation — To create/update the data
- Subscription — To subscribe to the particular event
Query is nothing but it describes the data that you want to fetch from a GraphQL server. When you send a query, you ask for units of data by fields. These fields map to the same field in the JSON data response you receive from your server.
query {
allStudents{
firstName
secondName
year
}
} Note : Successful queries return a JSON document that contains a data key. Unsuccessful queries return a JSON document that contains an errors key.
When we write queries, we are selecting the fields that we need by encapsulating them in curly brackets. These blocks are called selection sets. These fields are directly related to GraphQL types.
Mutations :
So we know that, Queries describe all of the reads that happen in GraphQL. Mutations are used to,
- Create new data
- Update existing data
- Delete existing data
The syntax for mutations look almost the same as queries, but they must start with the mutation keyword. It looks a lot like queries; it also has names and also has selection sets, but their intention is to change something about the overall state of an application.
mutation { createStudent(firstName:"Rathesh" , secondName:"Prabakar" , year:"III"){ firstName
secondName
year }
}
So here, We are adding a student to our database with the parameters of firstName , secondName and year .
Subscriptions is a way of establishing and maintaining the real time connection to the server. This enables the client to get the information based upon the events. To be generic, the client will subscribe to an event on the server, and whenever that event is called, the server will send the corresponding data to the client.
In our example, we will want to get updates from the server whenever a new student is joined that way we can update the client automatically without having to make a call for it.
subscription
{
newStudent {
firstName
year
}
}End of Part — 1 era
In this article we introduced the GraphQL, walk-through deeply about the REST vs GraphQL, Origin of GraphQL, Concept of queries, mutations and subscriptions. In the upcoming articles, we will see some intermediate concepts in GraphQL, then surely we are ready to get our hands dirty by starting to design a schema for our surprise application !!
Note : Surprise will be revealed in our next article, So stay tuned and let’s execute Subscriptions to my interesting GraphQL world.
If you have any questions or observations, feel free to use the comment section
