How is the Caching eTag Support for the Library If I use Apo

Question

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

Dariusz Kuc · Answer

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

Dariusz Kuc · Answer

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 · Answer

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 · Answer

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

mbonnin · Answer

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

Robert · Answer

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 · Answer

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

mbonnin · Answer

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 · Answer

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 · Answer

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 · Answer

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

mbonnin · Answer

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