How is the Caching / eTag Support for the Library? If I use Apollo Client on the Frontend, would I b...

# graphql-kotlin

[Robert]

How is the Caching / eTag Support for the Library?
If I use Apollo Client on the Frontend, would I benefit from caching?

[Dariusz Kuc]

Currently we don’t have any out-of-box support for setting up the etag/cache headers on the response

[Dariusz Kuc]

i’m not familiar with Apollo caching logic so unsure whether they would be any benefit there (my understanding is that it might still be able to cache some parts of your query)

[Dariusz Kuc]

as for setting up custom response headers you could create custom route or query handler to set it up (https://github.com/ExpediaGroup/graphql-kotlin/blob/master/graphql-kotlin-spring-server/src/main/kotlin/com/expediagroup/graphql/spring/execution/QueryHandler.kt)

[Dariusz Kuc]

but i guess you would need some mechanism to determine what header value to set

[mbonnin]

Hi 👋 .

If I use Apollo Client on the Frontend, would I benefit from caching?

If you're using HTTP caching, I guess the browser will cache the HTTP responses without Apollo knowing about it? If your GraphQL queries use HTTP POST, I'm not sure this option would work though so you might have to use GET instead.
Another option is to use the Apollo normalized cache and not use the browser HTTP cache. This doesn't require eTag and handles expiration on the client side.

[Robert]

Hey thanks for the Input! I also don't know yet how the default Apollo Caching would work.
AFAIK GraphQL can only support POST by design?

[mbonnin]

I've seen people write the GraphQL queryDocument as a HTTP query param, although that seems to be a very small minority

[mbonnin]

Overall, I think using the normalized cache in clients is easier to work with because it allows other use cases like deduplicating data and listening to cache changes

[Dariusz Kuc]

Yeah many servers (including gql kotlin) support get with query parameters but due to size limitations of the url it is generally not feasible for larger queries

[Dariusz Kuc]

*unless you use something like persisted queries where you send hash of a query in url (which in turn could be potentially cached by akamai)

[Dariusz Kuc]

Sounds like Apollo normalized cache is the way to go for client side caching

[mbonnin]

A bit late to the party but I just stumbled on this article https://www.apollographql.com/blog/graphql-caching-the-elephant-in-the-room-11a3df0c23ad/
It is a good recap of the challenges of doing HTTP caching with GraphQL