A modern programming language that makes developers happier.

kotlinlang

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

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

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)

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>)

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

Hi :wave: .
&gt;  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 <https://www.apollographql.com/blog/demystifying-cache-normalization/|normalized cache> and not use the browser HTTP cache. This doesn't require eTag and handles expiration on the client side.

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?

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

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

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

*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)

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

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