How was GraphQL born?

You will find stereotype definitions on the internet of GraphQL in which you won't easily understand what actually it is.

As a developer, We sometimes just need to understand the simple purpose of any technology, and then we can learn and code at our own. So I have written this article to share my understandings of GraphQL. This article will help you to get started with GraphQL.

I am dividing this article into two parts to have a proper understanding of what GraphQL actually is.

• Problems in REST
• The solution

Problems in REST

1. The hard coded static structure of REST

• In the REST, generally the response fields are fixed, whether we need all fields or not, we get the object fields that are fixed with that API so let's say you need the name of all the countries, you will make API request to http://yourserver../countries which will give your response and the response will be like

[
    {
        "name": "Afghanistan",
        "topLevelDomain": [
            ".af"
        ],
        "alpha2Code": "AF",
        "alpha3Code": "AFG",
        "callingCodes": [
            "93"
        ],
        "capital": "Kabul",
        "altSpellings": [
            "AF",
            "Afġānistān"
        ],
        "region": "Asia",
        "subregion": "Southern Asia",
        "population": 27657145,
        "latlng": [
            33.0,
            65.0
        ],
        "demonym": "Afghan",
        "area": 652230.0,
        "gini": 27.8,
        "timezones": [
            "UTC+04:30"
        ],
        "borders": [
            "IRN",
            "PAK",
            "TKM",
            "UZB",
            "TJK",
            "CHN"
        ],
        "nativeName": "افغانستان",
        "numericCode": "004",
        "currencies": [
            {
                "code": "AFN",
                "name": "Afghan afghani",
                "symbol": "؋"
            }
        ],
        "languages": [
            {
                "iso639_1": "ps",
                "iso639_2": "pus",
                "name": "Pashto",
                "nativeName": "پښتو"
            },
            {
                "iso639_1": "uz",
                "iso639_2": "uzb",
                "name": "Uzbek",
                "nativeName": "Oʻzbek"
            },
            {
                "iso639_1": "tk",
                "iso639_2": "tuk",
                "name": "Turkmen",
                "nativeName": "Türkmen"
            }
        ],
        "translations": {
            "de": "Afghanistan",
            "es": "Afganistán",
            "fr": "Afghanistan",
            "ja": "アフガニスタン",
            "it": "Afghanistan",
            "br": "Afeganistão",
            "pt": "Afeganistão",
            "nl": "Afghanistan",
            "hr": "Afganistan",
            "fa": "افغانستان"
        },
        "flag": "https://restcountries.eu/data/afg.svg",
        "regionalBlocs": [
            {
                "acronym": "SAARC",
                "name": "South Asian Association for Regional Cooperation",
                "otherAcronyms": [],
                "otherNames": []
            }
        ],
        "cioc": "AFG"
    },
.
.
.

So you want to fetch just name and you're getting other fields for free!
Actually it's not free and that is the second problem of REST.

So some of you say, we should have a different API for fetching the only name if we need that in our project and I say we can definitely do that but Should we?
Just think, How many APIs you need to create for medium to the large size of the project?
Not feasible, right?

2. Performance

So in the above example of fetching countries, you will think we are just getting extra data that we are not showing on the UI. Well, it causes a few issues like

• Increase the downloading time of API response
• Processing of fields from the database and also perform some calculation if needed on that, but in the end, those fields are not required.
• Unnecessary data slows down the browser.

3. Multiple API calls

In REST We have to do many API calls for building a structure on UI. Like, If I want to display a student's result related data on the table then I first have to fetch the students. And then for each of the students, I have to do an API call for fetching the result. So for 100 students, there will be 101 API calls. And practically, API calls overhead increases and it also cuts down performance.

Solution

So above mentioned problems have given birth to GraphQL
Let's see how we can tackle the problems we discussed above through it.

1. In GraphQL, you have to mention which fields you want in the call response and you get only what you want. So no more and no fewer fields in response.
   In GraphQL, you have to make POST request for everything and have to mention the field names you want in the POST method body so the backend can only process and perform calculations on those fields only and sends back the response.

2. In countries example

   the size of country data with every field is 254.69KB
   the size of country data with the only name is 3.53KB

So we save some space on the browser and also downloading time will also be decreased.

1. We can fetch everything in a single call, We can design GraphQL structure in a way that in a single API request we get the required data which is not practically possible but we can save many API calls.

So basically, GraphQL makes HTTP request-response dynamic and flexible. It's not magic, we also have to configure the backend API but it's a nice concept/architecture that solves existing issues of REST.