-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[apollo-datasource-rest] Feature request: expose cache status to callers #41
Comments
This field is returned if you call `fetch` instead of `get` (etc) and it tells you what the deduplication policy was and if it matched. Also allow `this.fetch` to be called with only one argument (because we previously made `method` optional). Part of #41 (which also requests adding information on the other cache's status).
This field is returned if you call `fetch` instead of `get` (etc) and it tells you what the deduplication policy was and if it matched. Also allow `this.fetch` to be called with only one argument (because we previously made `method` optional). Part of #41 (which also requests adding information on the other cache's status).
This gives us an appropriate place to put the data desired by #41. Also makes RESTDataSource tests actually wait on the cache writes (perhaps they were brittle before).
This gives us an appropriate place to put the data desired by #41. Also makes RESTDataSource tests actually wait on the cache writes (perhaps they were brittle before).
This is a good feature suggestion and we're partway there now:
We're not going to have time to implement the rest of this as part of the development spike we're doing right now, but if somebody else wanted to add more fields to |
Not sure if I need to put the PR in |
Hey folks 👋 We have an existing subclass of
RESTDataSource
that logs a variety of metrics for each call tofetch
. We're trying to instrument our data sources to better understand how caching/memoization is used in production. However,RESTDataSource
doesn't make it easy to figure out this information; the best we could do was manually querying the cache andmemoizedResults
to try to infer what's happening. However, in the end, we ended up forkingRESTDataSource
/HTTPCache
to make cache status information first-class data in the return values fromget
/post
/etc. We defined a new type,FetchResult
that wraps the original response with cache metadata:We then updated the
get
/post
/etc. to return aFetchResult
:Finally, we changed
RESTDataSource#fetch
andHTTPCache#fetch
to return objects with that samecontext
property. With this, we could update our subclass ofRESTDataSource
to automatically report whether particular requests were served by the cache or were memoized.Here's our implementation in a Gist: https://gist.github.com/nwalters512/472b5fb7d4cc7d32c4cecaa69b21baf5. The important bits:
FetchResult
get
/etc.cacheHit: false
fromHTTPCache#fetch
cacheHit: true
fromHTTPCache#fetch
cacheHit
for revalidated cache dataHTTPCache
memoized: true
for memoized requestsWhile this works, it's less than ideal to have to fork
RESTDataSource
andHTTPCache
, since that introduces additional maintenance burden on our team. Ideally, this could be provided by theapollo-datasource-rest
package itself. Does Apollo have any interest in adding this functionality? It doesn't necessarily need to use the sameFetchResult
interface we invented, but we'd appreciate anything that would give us more insight into how the cache is used.The text was updated successfully, but these errors were encountered: