[
https://issues.apache.org/jira/browse/SLING-9655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bertrand Delacretaz updated SLING-9655:
---------------------------------------
Description:
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. This allows these responses to be
cached by the usual front-end HTTP caches, CDN etc.
* 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
was:
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
> 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. This allows these responses to
> be cached by the usual front-end HTTP caches, CDN etc.
> * 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)
