Response body size anomaly | Does Apollo have a standard data response compressor protocol?

[Jo-Eck]

Hello people,
I have noticed the following anomaly in my tests for a simple Apollo GraphQL server & client. I sent 1000 queries to the server with random IDs from a table and then evaluated the average data volume. My results showed that GraphQL used 3.2 times fewer data in the body than when I made the exact same requests via REST.

The same occurred for the first test case in paralleled form (multiple queries [50] over one request) as well with just less 88 000 bytes.

So my question is, does Apollo have any protocol active by default that compresses the response size in some way? After all, it’s basically the same data and shouldn’t have such immense differences.

My only explanation would be that the data was already present at the Apollo client and so the data size was reduced, but at that time the cache was actually disabled.

In the two graphs below, you can see the average data volume. The anomaly occurs in test case 1, especially since the phenomenon occurred in the opposite way in test case 5…

[Jo-Eck]

Here the second graph:

[JeffAuriemma]

Hi @Jo-Eck welcome to the forum! Interesting question. With the information given it’s hard to tell what might be happening under the hood. A few thoughts:

@Jo-Eck

My only explanation would be that the data was already present at the Apollo client and so the data size was reduced, but at that time the cache was actually disabled.

Can you elaborate on how you disabled the cache? That might help narrow things down a bit.

@Jo-Eck

My results showed that GraphQL used 3.2 times fewer data in the body than when I made the exact same requests via REST.

I think the details will matter here - I don’t quite understand how the requests (and responses?) could be the exact same between GraphQL and REST.

You might also be aware of the concept of query deduplication. Apollo Client will not send a query over the wire if there is an identical in-flight query. I don’t think that’s necessarily a factor here since you’re using random IDs but I thought it was worth mentioning just in case.

Anyhow, thanks for sharing your data, that’s an interesting comparison and it would be great to learn more.

[Jo-Eck]

Hi @JeffAuriemma, thanks for the first answer!
I know it is a little generally explained, but I thought maybe is there another technology what I do not know about yet.

@JeffAuriemma

You might also be aware of the concept of query deduplication. Apollo Client will not send a query over the wire if there is an identical in-flight query. I don’t think that’s necessarily a factor here since you’re using random IDs but I thought it was worth mentioning just in case.

Good mention, but I already know about this, in another test case (which is not displayed here), I could see for myself how this technology works.

@JeffAuriemma

Can you elaborate on how you disabled the cache? That might help narrow things down a bit.

The in-memory cache for the Apollo-Server (with default settings) was active and the Apollo-Client used by default only the browser cache according to my understanding. The test results I have recorded over the Google Chrome Console in the ‘Network’-Tab and export them via HAR (HTTP Archive). For each recording of one test case, I reset the log via ‘clear’ with the enabled setting ‘Disable cache’. I assumed that the corresponding cache was now cleared

Also, as I mentioned before, I ran test case 1 again on another day to rule out that it was the cache. For this, I completely restarted client and server with the premise that they have no data in the cache.

@JeffAuriemma

I don’t quite understand how the requests (and responses?) could be the exact same between GraphQL and REST.

The only difference between GraphQL and REST queries is their special query form. As I said the IDs are all exact the same and unique. So the queries looked like this:
After my understanding GraphQL request all data via the body. Over the watchQuery(…) function of apollo i passed the query and the variabe value.

query Product($productid: Int!) {
     product(PRODUCTID: $productid) {
        # table fields ...
     }
}

And for REST I used only URL parameters:

http://..../products/query?productid=5

@JeffAuriemma

Anyhow, thanks for sharing your data, that’s an interesting comparison and it would be great to learn more.

Yes, this is an interesting comparison, this is also one of the points why I am investigating this in my bachelor thesis

I hope this information gives you a better understanding and overview

[JeffAuriemma]

@Jo-Eck

After my understanding GraphQL request all data via the body. Over the watchQuery(…) function of apollo i passed the query and the variabe value.

Were the responses the same as well?

@Jo-Eck

The in-memory cache for the Apollo-Server (with default settings) was active and the Apollo-Client used by default only the browser cache according to my understanding. The test results I have recorded over the Google Chrome Console in the ‘Network’-Tab and export them via HAR (HTTP Archive). For each recording of one test case, I reset the log via ‘clear’ with the enabled setting ‘Disable cache’. I assumed that the corresponding cache was now cleared

One clarification: InMemoryCache is part of the Apollo Client package, Apollo Server has different abstractions for caching. Your response about disabling the cache via the browser dev tools helped me narrow things down a bit. I think you’d find these links instructive:

Caching in Apollo Client

Demystifying Cache Normalization

In short, Apollo Client’s InMemoryCache, which is a normalized cache, is designed to reduce the total amount of data your app needs to fetch over the wire. That may account for the delta you observed.

[Jo-Eck]

@JeffAuriemma

Were the responses the same as well?

Yes they were.

@JeffAuriemma

One clarification: InMemoryCache is part of the Apollo Client package, Apollo Server has different abstractions for caching.

Oh sorry, you’re right, I had that wrong in my head. I apologize, I assumed that I could disable caching momentarily via the Chrome Console. With an active cache that is also normalized, the large delta makes much more sense. Thanks for your help.