Hi, On Fri, Aug 7, 2020 at 4:48 PM Andreea Miruna Moise <[email protected]> wrote: > > 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?...
We might extend that servlet to support this behavior, I think that's an implementation detail. > > 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... Yes, and I think a module or utility class that does this can be useful in other parts of Sling. > > 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. .. We could also provide extension points to do that, without providing an actual cache implementation, see below. > It just seemed a simpler solution... Apart from small internal things like caching servlet resolution I don't think we've been doing that kind of caching in Sling so far so I prefer avoiding it if possible. Delegating caching to the HTTP layer is much more consistent with what we're doing already. -Bertrand
