> 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" <[email protected]> wrote:
Hi Andreea,
On Fri, Aug 7, 2020 at 12:41 PM Andreea Miruna Moise
<[email protected]> 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
