[jira] [Comment Edited] (SLING-9655) Caching support for the GraphQL core

["Bertrand Delacretaz (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SLING-9655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17177022#comment-17177022 ] 

Bertrand Delacretaz edited comment on SLING-9655 at 8/13/20, 1:41 PM:
----------------------------------------------------------------------

h3. HTTP response headers related to caching

I've done a bit of reading of [https://www.ietf.org/rfc/rfc2616.txt] (the HTTP/1.1 spec) to refresh my understanding of caching headers, here's a summary:
 * HTTP/1.1 requires origin servers to send a *Date* header, if possible, with every response, giving the time at which the response was generated. This is used by caches to compute the response's age.
 * A *Cache-Control: max-age=<nSeconds>* header should be sufficient for basic caching, but we should also include the "*public*" or "*private*" modifier as per section _14.9.1 What is Cacheable_. I suppose we'll use "public" for the anonymous Oak user and "private" for authenticated requests.

[https://developers.google.com/web/fundamentals/performance/get-started/httpcaching-6] and [https://jakearchibald.com/2016/caching-best-practices/] are good sources of additional information.

If we want to later use cache duration hints provided by {{SlingDataFetcher}} services, we should create a utility class for the logic that combines those hints to generate the caching headers. That might be useful in other parts of Sling, but we can start with a class in its own package in this module and move it later if needed.


was (Author: bdelacretaz):
h3. HTTP response headers related to caching

I've done a bit of reading of [https://www.ietf.org/rfc/rfc2616.txt] (the HTTP/1.1 spec) to refresh my understanding of caching headers, here's a summary:

 * HTTP/1.1 requires origin servers to send a *Date* header, if possible, with every response, giving the time at which the response was generated. This is used by caches to compute the response's age.
 * A *Cache-Control: max-age=<nSeconds>* header should be sufficient for basic caching, but we should also include the "*public*" or "*private*" modifier as per section _14.9.1 What is Cacheable_. I suppose we'll use "public" for the anonymous Oak user and "private" for authenticated requests.

[https://developers.google.com/web/fundamentals/performance/get-started/httpcaching-6] and [https://jakearchibald.com/2016/caching-best-practices/] are good sources of additional information.

If we want to later use cache duration hints provided by {{SlingDataFetcher}} services, we should create a utility class for the logic that combines those hints to generate the caching headers.  That might be useful in other parts of Sling, but we can start with a class in its own package this module and move it later if needed.

> Caching support for the GraphQL core
> ------------------------------------
>
>                 Key: SLING-9655
>                 URL: https://issues.apache.org/jira/browse/SLING-9655
>             Project: Sling
>          Issue Type: Task
>          Components: GraphQL
>    Affects Versions: GraphQL Core 0.0.4
>            Reporter: Bertrand Delacretaz
>            Assignee: Radu Cotescu
>            Priority: Major
>
> We've discussed [on our dev list|https://lists.apache.org/thread.html/r00652fa5bc54f96bb3ec01264905d9a1f36677a71070fa1b724570f9%40%3Cdev.sling.apache.org%3E] how to provide caching support and we'd like to leverage front-end HTTP caches that people usually use in front of Sling.
> What we've discussed is:
> * 1) GraphQL queries executed via POST are not cached by Sling
> * 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 HTTP
> Cache headers which might (maybe in later phase) 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



--
This message was sent by Atlassian Jira
(v8.3.4#803005)