How to ensure findOneById bypasses the cache and gets the data from the database?

[doronrk]

There doesn't seem to be a way to ensure that findOneById gets its value directly from the database. If TTL is unset, then the read will not populate the cache after fetching the document, but it will always try to get the key from the cache regardless of the value of TTL.

Is there a particular reason why this behavior is not supported? Sometimes when a use-case isn't supported, it makes me think I'm barking up the wrong tree. However, it seems reasonable to want to ensure that a given query gets the latest value from mongodb, even if a subsequent load was issued with a non-zero TTL.

Thoughts?

[doronrk]

Let's say you have two different gql resolvers. Resolver A comes under very heavy load and can return slightly stale values. Resolver B is hit rarely, but must return the latest value.

Resolver B still wants to take advantage of the DataLoader semantics which guarantee that at most one db-fetch is issued for a particular ID, but this one db-fetch must come from mongodb, not Redis.

Meanwhile, Resolver A is constantly causing Resolver B to get cache hits from Redis, because findOneById unconditionally checks redis first and returns early.

Possible solution A: This package could make the dataloader instance available to subclasses.
Possible solution B: My subclass could initialize its own dataloader, but I don't love this because then you have two dataloaders per datasource per request. This is wasteful, and could lead to a situation where the same id is fetched twice in a single request, once for each dataloader.

solution A seems preferable. Would you accept a PR for that?

[lorensr]

Makes sense! Pro/cons of A vs adding an option like findOneById(id, { bypassCache: true })?

[doronrk]

Thanks for the fast response @lorensr !

I think the API you proposed is reasonable, but there is one drawback. Does bypassCache refer to just the read, or also the write-back? Hypothetically, a subclass could want to do any combination of bypassCacheOnRead: yes/no, writeToCache: yes/no.

I think the drawback is that some future person like me might open another issue asking for this. If you let the subclass access the dataloader, this provides the most flexibility.

Thoughts?

[lorensr]

Sounds good, would appreciate PR for A, thanks ☺️

…

On Fri, Oct 16, 2020 at 12:15 AM Doron Roberts-Kedes < ***@***.***> wrote: Thanks for the fast response @lorensr <https://github.com/lorensr> ! I think the API you proposed is reasonable, but there is one drawback. Hypothetically, a subclass could want to do any combination of bypassCacheOnRead: yes/no, writeToCache: yes/no. I think the drawback is that some future person like me might open another issue asking for this. If you let the subclass access the dataloader, this provides the most flexibility. Thoughts? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#38 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAB5LGBMBQCGBLE4XFIZTCLSK7CF3ANCNFSM4SRNARUQ> .

[doronrk]

Cool. I'm living the startup life at the moment, but will try and get to this.