Introduction to GraphQL

What is GraphQL?

GraphQL stands for Graph Query Language. It is an API specification standard and, as its name says – a data query language. At its core, GraphQL enables declarative data fetching where a client can specify exactly what data it needs from an API. Instead of multiple endpoints that return fixed data structures, a GraphQL server only exposes a single endpoint and responds precisely to the client’s requested data.

API and query language

To better understand GraphQL, we will explain in short terms what API is (an acronym for application programming interface) and what query language is.

API is the acronym for application programming interface – a software intermediary that allows two applications to talk to each other.

Let’s say you are ordering food online and paying through a web application. Most of those communications will probably happen via API behind the scene. The web application will use APIs to connect user-facing front ends with back-end functionality and data. The server then retrieves that data, interprets it, performs the necessary actions, and sends it back to the user’s application. The application then interprets that data and presents it to the user with the information in a readable way. In simple words, API allows two applications to talk to each other.

[source]

In addition to the above, to get that response, we need to write and send some kind of query, and for that, we use query language. So query language is a language that is used to retrieve information from a database.

GraphQL workflow

GraphQL server with a connected database represents a major use case of GraphQL. In this kind of setup we would have a single (web) server that implements the GraphQL specification. The client needs to send information to the server to express its data needs – and that information is called a query.

When a query arrives at the GraphQL server, the server reads the query’s payload and fetches the required information from the database. This is called resolving the query. It then constructs the response object as described in the official specification and returns it to the client.

In general, GraphQL isn’t tied to any specific database or storage engine and is instead backed by your existing code and data. GraphQL doesn’t care about the database or the format that is used to store the data. 

Now, wouldn’t it be great to get exactly the data you need via API request using only one endpoint? As mentioned above, we can see that GraphQL’s workflow is very clear; it can be described through three parts Describe, Ask and Get predictable results. So, let’s look at it using a very simple scenario by fetching (request) data via GraphQL that will hit the server, fetch some data from the database, and get back with the response.

For this example, let’s assume we have a simple database with restaurant data. The diagram below shows the simple structure and relations in the database. 

To clarify this example, sample data for the restaurants we will use is added to the table below.

For instance, let’s assume you want to send a query to get responses with restaurant names. We’ll create a query called, e.g., “restaurantSearch.” We’ll use declarative syntax to query the data we need from the client to the server. It would look like this:

query restaurantSearch {	
   restaurants {	    
        name
    }
}

As you can see, the query we are sending to the server side is pretty self-explanatory, we are trying to fetch the restaurant names.

Based on the above query, GraphQL would generate the payload, which will have a JSON response with data on it. If we take into account the data from the database above, the response would look like this:

“Data”: {
      “restaurants”: [
    {
         “name”: “Burger House”
     },
    {  
         “name”: “Firenze Pizzeria”
     },
     { 
         “name”: “Vege food”
     }
]

Furthermore, let’s say that you want only restaurants with pizza food type to be listed in the response. In that case, you can provide an argument and get a more specific response.

query restaurantSearch {	
     restaurants({foodType: “pizza”}) {	    
          name
    }
}

In response from this query, only restaurants with pizza food type will be listed:

“Data”: {
      “restaurants”: [
     {
         “name”: “Firenze Pizzeria”
     }
]
}

Finally, the server sends “Firenze Pizzeria” to the client, and that restaurant gets displayed on the client’s device, e.g., iPad.

GraphQL benefits

Besides providing various benefits for developers, GraphQL also provides very useful benefits for QA engineers. Let’s look at some of them.

Data fetching – GraphQL queries help to smoothly retrieve associated business objects, while typical REST APIs require loading from multiple URLs. GraphQL APIs fetch all the data your application needs in a single request from one endpoint. In other words, no more over and under-fetching of data. GraphQL gives you precise data.

Data Operation: In REST API, each resource is represented with an endpoint, and it’s apparent to end up having multiple endpoints. Whereas, In GraphQL, everything is perceived as a graph, and it’s connected and represented as a single endpoint.

As mentioned in the paragraph above, GraphQL allows more precise querying. That is one of the most significant benefits, especially when working with large APIs that return a lot of data. 

Conclusion

As we have seen above, GraphQL follows the WYAIWYG pattern or What You Ask Is What You Get, and the queries will always return predictable results. 

GraphQL is designed to make APIs fast, flexible, developer-friendly, and QA engineer-friendly. This way, testing API on applications with GraphQL implemented will provide better possibilities for testing and quality assurance.