GraphQL GET response time is slow when comparing to RESTful

Question

I wanted to test the response times of a GraphQL endpoint, and a RESTful endpoint as I haven't ever used GraphQL before, and I am about to use it in my next Laravel project.

So I am using Lighthouse PHP package to serve a GraphQL endpoint from my Laravel app, and also I have created a RESTful endpoint.

Both endpoints(GraphQL and RESTful) are intended to get all Users(250 users) from my local Database.

So based on the test what I have noticed here is that, when I tested this both endpoints on Postman, the RESTful endpoint response is faster than GraphQL endpoint.

Can I know why GraphQL endpoint's response takes more time than RESTful while both endpoints are getting same data?

GraphQL endpoint result for GET request (response time: 88ms)

GraphQL endpoint result for POST request (response time: 88ms)

RESTful endpoint result (response time: 44ms)

Sensationalism

You eont know without profiling it. My guess is that in this example you're paying for the additional processing graphql does (calculating the selection set, returning only required fields), but not gaining anything in return. If you want real comparison, do some more complex requests – Divert

@kaz did you try POST request for graphql api for get users list. As graphql follow POST request for everything. – Pru

@Pru as on the GraphQL official doc graphql.org/learn/serving-over-http, I have sent the request over GET request. Anyways, I'll try it with POST request, and let you know. – Sensationalism

@NirLevy What do you mean by complex requests? – Sensationalism

@Pru I have sent it over POST request, but still the response time is same. You can see the result in the screenshot which I have posted above with the question. – Sensationalism

Answer 1

There's no such thing as a free lunch.

GraphQL offers a lot of useful features, but those same features invariably incur some overhead. While a REST endpoint can effectively pull data from some source and regurgitate it back to the client, even for a relatively small dataset, GraphQL will have to do some additional processing to resolve and validate each individual field in the response. Not to mention the processing required to parse and validate the request itself. And this overhead only gets bigger with the size of the data returned.

If you were to introduce additional features to your REST endpoint (request and response validation, support for partial responses, ability to alias individual response fields, etc.) that mirrored GraphQL, you would see the performance gap between the two shrink. Even then, though, it's still somewhat of an apples and oranges comparison, since a GraphQL service will go through certain motions simply because that's what the spec says to do.

Waste

Daniel, any graphlq-php alternatives for Lighthouse that you'd recommend to use in Laravel? – Sensationalism

Answer 2

TLDR: Your REST example is simple and less complicated

In Lighthouse it is creating a AST for parsing the graphql request and your schema. It then afterwards passes all the directives and so on to figure out what you are trying to do. It also has to validate your query, to see if you can actually run it on the schema.

Depending on how you defined it in your application, there is a lot of steps it is passing through. However this can be reduced by multiple different ways, the parsing of your graphql schema can be cached, you could cache the result, use deferred fields (prob. wont speed up this example). You can read more about this in the performance section of the docs.

You are not specifying how your REST is setup, if you are using some kind of REST standard where it has to parse the data also. If you add more features, there is more code to run through, hence higher load speed.

Voroshilovgrad

Any graphlq-php alternatives for Lighthouse that you'd recommend to use in Laravel? – Sensationalism

Rebing and folklore has a graphql package also. But I'll say lighthouse is the best of them with most features – Voroshilovgrad

Answer 3

As of Lighthouse v4, we have made significant performance increases by lazy-loading the minimally required fields and types from the schema. That turns out to bring about a 3x to 10x performance increase, depending on the size of your schema.

You probably still won't beat a single REST endpoint for such a simple query. Lighthouse will begin to shine on more heavily nested queries that join across multiple relationships.

Compile

Answer 4

Try enabling opcache on the server. This decreased my gql response time from 200ms to 20ms

Govea