Hi Bertrand, > On 7 Aug 2020, at 16:18, Bertrand Delacretaz <[email protected]> wrote: > > 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
Instead of replying with a 404 and asking the client to do another POST + GET, couldn’t we just return the updated results with updated cache headers? Judging by how you describe the algorithm, the Sling server would still have to maintain a cache internally. And we can return a 404 only when we purge the query from Sling’s internal cache, which doesn’t have to coincide with the moment the query’s results have to be updated. In my view the query’s endpoint is the resource, whereas what we return would be the resource’s version. This way we can reply with ETag and Cache-Control headers. Thanks, Radu
