Getting Started with GraphQL (Part I)

The purpose of this article is to highlight the basic understanding of GraphQL along with discussing the significant pros and cons associated with this particular APIs specification.

GraphQL is an open source server-side technology which was developed by Facebook. GraphQL is an execution engine and data query language to optimize REST APIs calls. Let’s understand in more detail about GraphQL.

What is GraphQL ?

Let me breakdown word Graph and QL. Graph means our queries cryoll into the REST APIs and pick up the selective information and QL means query language.

“GraphQL means query language designed to built client application by providing flexible and initiative syntax asking the data requirement by clients.” in simple terms design query more smarter way

GraphQL is designed to make APIs fast, flexible, and developer-friendly. As an alternative to REST, GraphQL lets developers construct requests that pull data from multiple data sources in a single APIs call.

Additionally, GraphQL gives APIs maintainers the flexibility to add or deprecate fields without impacting existing queries. Developers can build APIs with whatever methods they prefer, and the GraphQL specification will ensure they function in predictable ways to clients.

GraphQL allows making multiple resources request in a single query call, which saves a lot of time and bandwidth by reducing the number of network round trips to the server. It also helps to save waterfall network requests, where you need to resolve dependent resources on previous requests.

so far we mainly design APIs using REST and other web services.only problem with them is over fetching or under fetching. Sometimes data over fetching or under fetching need to create multiple APIs to fetch less or more data. Sometime u don’t needed more or less data. Only needed selective data.

Example :

Let say we have cricket teams from different countries. we have created endpoints to retrieve information of players . Using all endpoints we can collect information but information is not selective.

/players

/players/id

/country

Instead of REST APIs if we use GraphQL we don’t need to declare multiple endpoints also we can only retrieve information what we needed in the smarter way.

Instead of REST APIs if we use GraphQL we don’t need to declare multiple endpoints also we can only retrieve information what we needed in the smarter way.

GraphQL Query and Mutation

Query:

In REST, any request might end up causing some side-effects on the server, but by convention it’s suggested that use GET requests to retrieve data. In GraphQL we can retrieve data using the Queries.

Query have components like field, arguments, aliases, fragments, variables, operation name, directives etc.

Request:
query countryNameAndPlayers {
country {
          name
          players {
                   name
                  }
        }
}
Response :
{
  "data": {
    "country": {
      "name": "IND",
      "players": [
        {
          "name": "Test One"
        },
        {
          "name": "Test Two"
        }
      ]
    }
  }
}

As we can see query will return specific value like country name and player name no other arguments need to pass here.

Mutation:

Most discussions of GraphQL focus on data fetching, but any complete data platform needs a way to modify server-side data as well.

In REST, any request might end up causing some side-effects on the server, but by convention it’s suggested that one doesn’t use GET requests to modify data. GraphQL is similar — technically any query could be implemented to cause a data write. However, it’s useful to establish a convention that any operations that cause writes should be sent explicitly via a mutation.

Just like in queries, if the mutation field returns an object type, you can ask for nested fields. This can be useful for fetching the new state of an object after an update. Let’s look at a simple example mutation:

Request:
mutation createPlayerReview($pl: Player!, $review: ReviewInput!) {
createPlayerReview(player: $pl, review: $review) {
        stars
        commentary
    }
}
Input:
{
 "pl": "Test One",
     "review": {
           "stars": 5,
           "commentary": "He is a great player!"
    }
}
Response:
{
  "data": {
    "createPlayerReview": {
      "stars": 5,
      "commentary": "He is a great player!"
    }
  }
}

Note: How createPlayerReview field returns stars and commentary field of newly created review.

Now again it should be not consider that GraphQL is awesome in all area.

Sometimes application not need that kind of dig up into the information and that kind of resource that u need to implement GraphQL.

Remember that not everything comes up as new not always rainbow and sunshine. There are always pros and cons available.

Pros and Cons of GraphQL :

As they are both specifications for building and consuming APIs, GraphQL and REST have things in common. They both retrieve resources by sending queries, can return JSON data in the request, and be operated over HTTP. Also, REST endpoints are similar to GraphQL fields, as they are entry points into the data that call functions on the server

Thinking about trying GraphQL in a business or enterprise environment? It comes with both pros and cons.

Pros:

· A GraphQL schema sets a single source of truth in a GraphQL application. It offers an organization a way to federate its entire APIs.

· GraphQL calls are handled in a single round trip. Clients get what they request with no over fetching.

· Strongly defined data types reduce miscommunication between the client and the server.

· GraphQL is introspective. A client can request a list of data types available. This is ideal for auto-generating documentation.

· GraphQL allows an application APIs to evolve without breaking existing queries.

· Many open source GraphQL extensions are available to offer features not available with REST APIs.

Cons:

· GraphQL presents a learning curve for developers familiar with REST APIs.

· GraphQL shifts much of the work of a data query to the server side, which adds complexity for server developers.

· Depending on how it is implemented, GraphQL might require different APIs management strategies than REST APIs, particularly when considering rate limits and pricing.

· Caching is more complex than with REST.

· APIs maintainers have the additional task of writing maintainable GraphQL schema.

Conclusion:

Whole summary I would say when your REST APIs become smarter it’s called GraphQL. We have understand the Overview of GraphQL, Query and Mutation With Example, Pros and Cons of GraphQL Over the other webservice.

In Second Part We will be discuss about GraphQL Configuration, Schema and Types, Validation, Serving over HTTP Stay tuned for next blog.

Thank you for reading!

Any feedback would be much appreciated and if you liked what you’ve read please hold the clap button!