[
https://issues.apache.org/jira/browse/SLING-9655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17176183#comment-17176183
]
Ashish Chopra commented on SLING-9655:
--------------------------------------
the pattern described at [0] looks very interesting!
AIU this means the GraphQL client will:
* need a way to generate query-digest in the way Sling understands (maybe we'd
need to publish something for the clients to use)
* would need to transform how they issue HTTP requests - e.g., existing clients
that need to use Sling GraphQL will have to start expecting a 201 instead of
the response they'd typically expect when they POST with their payload
I wonder if instead of sending back a 201 Created from the POST request we
could follow the "POST/REDIRECT/GET" pattern - i.e., we include the digest-URL
to which (good clients!) that handle redirect can issue a GET to.
The advantage would be that existing clients will (hopefully) not need to be
adapted (to handle POST responses and 404s for GET) for leveraging GraphQL
caching.
The disadvantage would be that each such request will have to be (hopefully
minimally, though) processed by the Sling instance to consult the request-cache
and/or generate digest and update cache.
Thoughts?
[0]
https://lists.apache.org/thread.html/r7bfb9a40fd9c76506901eda9f7d10cfaa8077411d7956973902e462c%40%3Cdev.sling.apache.org%3E
> 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)
