Support more options in cache-control extension

[evans]

Totally agree that it would be great to add some more features. Curious which you are interested in and how you might see them play out in the extensions?

@jakubriedl wrote in apollographql/apollo-cache-control-js/#18

At this moment caching supports just maxAge and scope hints. it is a good start but there are much more features which should be supported. In general, it would be great if all applicable HTTP caching features would be supported.

To mention few which we need at this moment

• Age if the responded resource is not absolutely new we can respond the current age. So the cache time can be calculated as maxAge - Age and so we can prevent doubling the cache time.
• Vary we are using standard content negotiation for determining client language. This header allows to tell the engine what headers should be included in cache key to determine the correct response.

Also, it might be useful to integrate match and time-based validation (ETag, If-None-Match, If-Modified-Since) with the query using directives to reduce the amount of transferred data.

As a final note, I will mention that we are willing and able to help with design, development, and testing but you already know that 😃

[Tyler-Churchill]

I could see myself having some sort of "lock" hint. To prevent cache dog-piling or cache stampede it may be beneficial for a lock hint to be added. I would like to specify a lock so it would not be possible for my apollo-server instances to be computing the same cache value on expiry. For my use case, I would like to see 1 apollo-server instance compute the cached value while every other apollo-server instance still serves the stale value. I am sure that case will not work for everyone though so perhaps there would need to be a few options that can be configured in the hint. Something like @lock(keepStale=true)

[jakubriedl]

Great to see some traction for this so we can clean up the code. From our experience, the most valuable would be the mentioned Vary and Age.

And also it would be great to add more functions to manage the cache hints programmatically. These are things which we are doing on top of current (v1) features

• AST.cacheControl.mergeCacheHint(hint) when we are hitting multiple backend services we need to merge multiple hints coming from there. In that case, we need to do a little trickery to achieve that.
  • something which would allow to pull hints combined to headers from context/AST and set them to response.
  • disable cache in paths where is also error. We are using reasonable defaults when there is a problem in some resolver. But in that case we still write error to response.errors so clients know that the field was not resolved properly. In that case we disable cache for that field.
  • cache inheritance - not sure if this is needed but it case that the parent object has caching configured we set the same policy/hint to all children