Cacheing in progress events issue about datasource-rest HOT 4 CLOSED

@kowther Sorry for the delay: we are finally returning this project to active maintenance. What you're describing does seem like a bug: RESTDataSource is supposed to memoize these simultaneous identical calls (and in fact if anything it's too aggressive in doing so). (The two-level caching strategy used by RESTDataSource is finally documented.

Unfortunately the repo you linked is no longer available so there's no way to debug this issue. Were you talking about two REST invocations coming from completely separate GraphQL operations/HTTP requests?

from datasource-rest.

I'm going to close this because I don't know how to reproduce it; I recognize that this is our responsibility for leaving RESTDataSource unmaintained for so long. If you're able to restore that repository (even without updating it to the latest version, which has changed a fair amount) I'd be happy to investigate!

from datasource-rest.

@glasser I made my repository public again so you can check it out

from datasource-rest.

RESTDataSource has two levels of caching (a fact that wasn't documented until very recently).

The first level is an in-memory "deduplication"/memoization cache that is shared only within a single RESTDataSource object (and ignores HTTP response cache headers). This cache allows you to skip a second concurrent fetch of the same URL when the first fetch isn't done.

The second level is shared across RESTDataSource objects (and across processes if you use a shared cache) (and observes HTTP response cache headers). This one only is written once the fetch is finished.

The Apollo Server v2/v3 dataSources API runs the dataSources handler once for each request, so the RESTDataSource objects you're creating in your handler are not shared across requests (this is the expected way to do things). We felt that this was not particularly clear which is why there is no dataSources API in Apollo Server v4 (you can set up data sources in your context function which is much more obviously request-specific). That means that the "in progress" cache correctly doesn't trigger.

The second level cache actually does trigger if you run the two requests in series in your shell script, so it's not entirely broken.

So overall I'd say this is working as intended. If you really do want to have cross-request de-duplication of identical requests you could create a single global instance of your RESTDataSource and share it in the context of multiple operations. However this is a very bad idea with the current implementation of RESTDataSource because the de-duplication cache caches all GET responses essentially forever. We are working on a v5 release which changes this to only de-duplicate concurrent requests (#100) and relies on the main header-sensitive cache for de-duplication of requests that don't overlap in time. So in the forthcoming v5 it would be more reasonable to have a long-lived RESTDataSource. (Of course you'd want to be sure that there's nothing user-specific about the requests that are made — by default the cache key for deduplication is just the URL, so if you're setting different headers based on the user context or something you'd want to add that to the cache key.)

from datasource-rest.