In this Blog Post we are going to look at the GraphQL HTTP Request sampler and look at how GraphQL requests can also be made using a HTTP Request sampler in case you are for some reason restricted to an earlier version of JMeter (the sampler was only introduced in JMeter 5.4).
We will also look at some of the principles of GraphQL.
If your application under test comprises of a GraphQL service, you are going to have to understand how to test it and some of the performance considerations that surround performance testing of GraphQL.
What is GraphQL
There are many articles on GraphQL online, with this being the GraphQL homepage
In simple terms GraphQL is a query language for API’s that returns data based on your request, let’s consider an application with 2 individual API’s the first returns customer personal data such as:
The second returns customer address details such as:
Address Line 1
Address Line 2
Years At Address
Now we are conscious that these are simple and not particularly likely in a real-world scenario, but they help demonstrate GraphQL.
From a development perspective let’s say you want to display a customer
surname and the
first line of their address on your web page then without GraphQL you would have to call your 2 individual endpoints and have 8 pieces of data returned (4 for each endpoint) and then some browser side logic or client software would need to extract the 3 pieces of data you needed.
With GraphQL you only need to request firstname, surname and address line 1 and those pieces of data are all that are returned.
Now this is a simple example, and you are probably thinking that it would just as easy to just call the 2 endpoints which is a fair point, however if your application under test has a much larger set of APIs and the data returned is more significant and you need to start performing complex joins and data aggregation on the data returned then the benefits of GraphQL become apparent.
Note that this blog post is not about the rationale behind whether your organisation should implement GraphQL or not it’s about the testing of the GraphQL queries (returns data, think GET) and mutations (updates data, think POST, DELETE, PATCH).
GraphQL Performance Testing Considerations
Test the internal APIs
We have touched on the concept that GraphQL aggregates data before returning the requested subset and therefore from a performance perspective this may be a performance bottleneck and needs to be considered when defining your performance testing.
To explore this further let’s go back to the simple example we outline at the start of this blog post.
Let’s call the customer personal details
api-1 and let’s call address details
api-2 and finally let’s call the GraphQL query
If under peak levels of load and concurrency gql-3 takes 2000 milliseconds and this fails your performance requirements because you want all responses to be back in 1000 milliseconds then a worthwhile additional performance test is to test api-1, api-2 and qgl-3 all under the same load to see if it’s the GraphQL layer that does not perform or one of the individual endpoints that GraphQL calls internally.
So, if under peak load:
|Service Name||Response Time|
Then the poor performance is not GraphQL its one of the endpoints that it calls, and this is the source of the performance issues.
It is always a good idea to not only performance test GraphQL but also all the endpoints that it calls all under the same load conditions so you can accurately demonstrate where the source of any performance issues may be, should there be any.
Use accurate queries
Another consideration when performance testing GraphQL is ensuring that the request you make to GraphQL is indicative of how it will be used in production, we will use our simple example to demonstrate.
Let’s say that we do indeed only need three pieces of data from our GraphQL layer as we discussed in the earlier section entitles What is GraphQL, then in production the development teams may write a query similar to this:
Which would call a query called customerDetails and take a parameter called customerId and then return 3 pieces of customer information.
We will discuss the structure of the GraphQL query in later sections so don’t worry if this does not make much sense now.
The thing with GraphQL is that it is possible to query it for any data attribute that it contains, and the request being made does not need to conform to any template other than the request must be syntactically correct and you must be asking for data that it knows about.
If in our JMeter test we constructed a request that requested all customer data
And when we ran our test under load it did not perform in line with our requirements then we would be unsure as to whether it was because of the GraphQL implementation not performing or the request we are making.
Again, in production systems the complexity of some of the queries can be high and using a query that will not be used in production can cause the application under test to work harder than it needs to, and you may be raising performance issues against conditions that will never materialise in production.
Because of the flexibility of GraphQL it is important to ensure you make you requests accurate with how they will be used in your application.
So that’s enough about the theory and things to look out for, lets look at building a test.
Building our test
We are going to start with building a GraphQL test with a HTTP Request Sampler as the GraphQL HTTP request Sampler was only introduced in JMeter 5.4 and it is possible that you may be using an earlier version of JMeter in your organisation for any number of reasons so it’s useful to understand how this can be done without the sampler that JMeter 5.4 offers.