Possibility to cache the parsed and validated results.

[stevengssns]

Hello,

We have a service (Apollo Server) running in production, which in some (non-trivial) cases can do a relatively large amount of downstream requests. Currently we are moving away from a custom cache implementation to this library, and this is partially done. However, for the next part of the code we seem to be suffering a performance hit which was nog present in our custom implementation.

Although we need further testing and verification to be absolutely sure, it is very likely that we can blame it on the JSON.parse() step that is always performed when retrieving a cached fetch. Even before doing our first test, we already identified this as a risk.

I have some idea about how we can fix this, while still re-using most of this library. But it will require at least the following changes to the current version:

• The caching behaviour needs to be exposed to the calling code. That way, the final objects can be cached separately with the correct ttl, without duplicating all the caching semantics code (in which case we could just as wel rewrite our existing custom library). I have already opened an initial PR what exposes some cache metrics that could be sufficient for this to work. And it is useful regardless of this issue.
• In case the cache is an in-memory cache, it will need to be possible to partially turn of the response caching. In this case I think it only makes sense to cache the responses that are eligible for re-validation, but with an empty body. Because the calling code will have cached the response as an object, and will have to evaluate what to do based on the cache metrics (i.e. is there a new response that needs to be parsed and cached or not?).

Fyi, my assumption is that this caching is should be done higher up, because I understand that serialising the cache entry to a string before storing it in the key value store makes it easy to switch between an in-memory or shared cache (e.g. redis).

It is my intention to open the necessary PR's for this. But before I progress beyond my first one, which seems to be a desired feature when browsing through the issues. I would like to obtain some feedback about my ideas.

• Does this idea seem legit, or totally crazy?
• If its not crazy, would it be something that you might want as an additional feature in the library? Of would it make more sense to only add the minimum that is required for users to implement this themselves (i.e exposing the caching metrics, and partially turning off the response caching)?

Kind regards,
Steven