[Hi Andreea, On Thu, Aug 6, 2020 at 12:02 PM Andreea Miruna Moise <san...@adobe.com.invalid> wrote: > What would be the recommended way of approaching caching in case of > GraphQL?...
I haven't given much thought to that so far, and reading [1] [2] and [3] it looks like the best way to cache GraphQL query responses is to run those queries server-side, driven by GET requests and use traditional HTTP caching. The GraphQL core module does support server-side queries, without caching HTTP headers so far but that could be added. But I suppose you are more looking at client-driven GraphQL queries. [3] mentions an interesting (if a bit hacky) way of moving queries to the server-side to make them easier to cache. I suppose that only works if you control the client and that's probably not a standard. > ...would it make sense to have an application caching layer at Sling level > that would support private > caching of the ExecutionResult?.. What we might do is provide hooks in the GraphQL Core for SlingDataFetchers to supply caching hints, along with an extension point where that caching can happen - would that work for your use cases? If the answer is yes, suggestions on how those hooks can look are very welcome! Although we do have caching services in Sling [4] I'm not sure if they are in active use at the moment, their code doesn't seem to have been touched in a long time. But if we provide somewhat abstract hooks, people can use whatever caching mechanism they want. -Bertrand [1] https://www.apollographql.com/blog/graphql-caching-the-elephant-in-the-room-11a3df0c23ad/ [2] https://www.apollographql.com/docs/apollo-server/performance/caching/#adding-cache-hints-statically-in-your-schema [3] https://github.com/apollographql/apollo-link-persisted-queries [4] https://sling.apache.org/documentation/bundles/caching-services.html
