> 3) Clients run such prepared queries by making GET requests to URLs like /graphqlservlet/prepared/cf81d4.json To be able to do this a different endpoint would be needed instead of org.apache.sling.graphql.core.servlet. GraphQLServlet right?
> 4) The responses to such prepared queries requests contain useful HTTP Cache headers, which might be set from hints supplied by data fetchers with configurable defaults. This means that sling would have to compute the headers based on the cache hints. On the other hand I was thinking that the KeyValueCache service can be implemented at the sling-graphql-adapter level and sling-graphql-core would only provide the interface. It just seemed a simpler solution. Regards, Andreea On 07/08/2020, 17:18, "Bertrand Delacretaz" <bdelacre...@apache.org> wrote: Hi Andreea, On Fri, Aug 7, 2020 at 12:41 PM Andreea Miruna Moise <san...@adobe.com.invalid> wrote: > ...1. In case we provide hooks for SlingDataFetchers we will end up with fine-grained cache hints... > But the major limitation is that this can be used only in case of GET requests.... > ...2. Now if we think of using POST requests that are not cached by CDN the only option is application > level caching... I've done a bit more research on GraphQL caching and in particular noticed the "Caching & GraphQL: Setting the Story Straight" talk by Marc-André Giroux [1] and I agree very much with his view. My summary of that is: -Like any flexible API, GraphQL is harder to cache than requests which have a narrower scope -There's no built-in way to use HTTP caching as GraphQL says nothing about which request/response protocol is used -Moving to a more HTTP-friendly way to express requests allows using HTTP caching. As you say, POST requests are usually not cached, and using GET is problematic due to the GraphQL query size. Which means that the client will need to do something beyond plain GraphQL requests, for caching to work. However, Sling-based systems usually have an HTTP cache in front, so if we can take advantage of that it avoids having to reinvent and maintain something else. I've also studied Apollo's "Automatic Persisted Queries" [2] which suggest a client/server protocol extension to cope with this. It's not as automatic as they claim IMHO but I like the general idea and I think we could do something similar for Sling while remaining within our usual HTTP best practices. Here's what I suggest: 1) GraphQL queries executed via POST are not cached bySling 2) Queries can be prepared in advance by POSTing the query text to Sling, which returns a "201 created" status with a URL that contains the query's digest, like cf81d4 3) Clients run such prepared queries by making GET requests to URLs like /graphqlservlet/prepared/cf81d4.json 4) The responses to such prepared queries requests contain useful HTTP Cache headers, which might be set from hints supplied by data fetchers with configurable defaults. 5) There's no guarantee on how long the prepared queries are stored, a client that gets a 404 on a prepared query request must be prepared to use the default POST request method or store the prepared query again I don't think we can achieve efficient caching without some collaboration with the client, and with this the requirements on the client are pretty simple to fulfill. Would that work for your use cases? -Bertrand [1] https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DCV3puKM_G14&data=02%7C01%7Csandru%40adobe.com%7C17470ed70bb843dd6ac508d83adcc578%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637324067161406786&sdata=wbx768cmx1qkOicioeJErI1xhPZHQPR5PZ%2FaHO8Kf%2BU%3D&reserved=0 [2] https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.apollographql.com%2Fblog%2Fimprove-graphql-performance-with-automatic-persisted-queries-c31d27b8e6ea%2F&data=02%7C01%7Csandru%40adobe.com%7C17470ed70bb843dd6ac508d83adcc578%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637324067161406786&sdata=ulttaOpdURR8M6mSNSHDb8AbNnrRkoY1Y5oGcqFd5%2Fg%3D&reserved=0