How to use CacheControl in DgsDataFetchingEnvironment

[jwalton922]

EDIT: My understanding was wrong, and many of my statements are wrong. Please see marked answer for useful information.

I'm trying to implement caching in a federated GraphQL API. I'm using Apollo Gateway for the federation server, and DGS for the subgraph APIs. Apollo's documentation shows a @CacheControl directive that is supposed to add caching information to the extensions field in the GraphQL response.

There is a Java GraphQL class graphql.cachecontrol.CacheControl which handles the logic of adding the extension, and I see that DgsDataFetchingEnvironment has an instance of the CacheControl in it via getCacheControl(). However, I do not think the caching hints I add to CacheControl object are not passed to the response by default.

I believe my options are to extend/modify the DGSRestController or the DefaultDgsQueryExecutor so that I can call the CacheControl method addTo(ExecutionResult result) on the instance of the ExecutionResult before it's returned. I feel like DefaultDgsQueryExecutor is the more direct approach, but it's not "open" so cannot be extended. I attempting to work around this by implementing my own DgsQueryExecutor that has an instance of DefaultDgsQueryExecutor that it uses, but it seems like a lot of work to add to the ExecutionResult.

I am nearly certain I'm missing an easier way to add the cacheControl extension. Does anyone have any ideas? If there is not an easier way, does it make sense to rquest a new feature that DefaultDgsQueryExecutor is open?

[setchy]

@jwalton922 - I've recently spent time diving into this rabbit hole.

The current graphql-java class graphql.cachecontrol.CacheControl was added many years ago and was based on the Apollo Cache Control Specification which has since been deprecated. My guess is that the aforementioned class in graphql-java should also be deprecated/removed. Note: this is different from the up-to-date Apollo server-side caching documentation. Some more details can be found here

Now for some good news, there is a open PR for federation-jvm which is very close to being merged and released, which adds in the same cacheControl support that apollo-server (graphql-js) uses. 🎉

Within the PR comments you'll see @berngp has been thinking about mechanisms which DGS could leverage this federation-jvm enhancement

[berngp]

Thanks @setchy!

PS. Planning to add some features that will allow us to include in the response the HTTP Caching Headers.

[setchy]

That'll be awesome @berngp. We have our own custom cacheControl logic and HTTP Header manipulation, so really really excited to adopt a more standard impl

[setchy]

@berngp - federation-jvm 0.8.0 is now released.

[berngp]

Noticed that today as well!

[jwalton922]

Thank you for the super fast response! I had several flaws in my understanding that those links helped clear up, and I will eagerly await for that PR to be merged and released.

[yamalameyooooo]

@jwalton922 did you soled this issue? i mean how did you implemented @CacheControl in the dgs project which gives cache-control in the response headers?

[CharlyRien]

I don't know if it can help, but to forward the @CacheControl directive that are indicated in our schema in the servlet http response headers we had to instrument our graphql queries with some Spring beans:

class CacheControlConfiguration {
    @Bean
    @Order(1)
    fun cacheControlResponseInstrumentation() = CacheControlInstrumentation() // Coming from com.apollographql.federation:federation-graphql-java-support

    @Bean
    @Order(2)
    fun forwardCacheControlHeaderBetweenGraphQLAndSpring() =
        object : Instrumentation {
            override fun instrumentExecutionResult(
                executionResult: ExecutionResult?,
                parameters: InstrumentationExecutionParameters?,
                state: InstrumentationState?,
            ): CompletableFuture<ExecutionResult> {
                val graphQLContext = parameters?.graphQLContext
                val cacheControlHeaderValue =
                    CacheControlInstrumentation.cacheControlHeaderFromGraphQLContext(graphQLContext)
                cacheControlHeaderValue?.let {
                    val dgsResponseHeaders = executionResult?.extensions?.get(DGS_RESPONSE_HEADERS_KEY) as? Map<*, *>
                    val updatedHeaders = dgsResponseHeaders?.plus(CACHE_CONTROL to it) ?: mapOf(CACHE_CONTROL to it)
                    executionResult?.extensions?.put(DGS_RESPONSE_HEADERS_KEY, updatedHeaders)

                    return CompletableFuture.completedFuture(
                        ExecutionResult
                            .newExecutionResult()
                            .from(executionResult)
                            .extensions(executionResult?.extensions ?: mapOf(DGS_RESPONSE_HEADERS_KEY to mapOf(CACHE_CONTROL to cacheControlHeaderValue)))
                            .build(),
                    )
                }

                return super.instrumentExecutionResult(executionResult, parameters, state)
            }
        }
}

It feels like a hack waiting for something being standardised but it is "doing the job" on our side.