Adding Caching Support

[RehanSaeed]

This client seems like a very thin wrapper over a HttpClient using dynamic. It would be nice to add many of the features in the Apollo JavaScript client such as client side caching.

You could use the IDistributedCache in the Microsoft.Extensions.Caching.Abstractions NuGet package to store cached objects. That package has lots of providers e.g. In-Memory and Redis built for it already.

[deinok]

The intention of enabling caching its part of the next release. First, I will put an abstraction over the caching mechanism, to enable a personalized caching mechanism, then add some kind of default caching. But first, I or somebody should have to thing a good API.

Any idea is accepted, but I dont think that IDistributedCache will help, nevermind, I will try to see the pros and cons of this API.

[SimonCropp]

@RehanSaeed have u considered leveraging http caching?

[RehanSaeed]

You mean supplying cachign HTTP headers from the GraphQL server? Isn't that very difficult to do because of the dynamic nature of it all?

[SimonCropp]

You mean supplying caching HTTP headers from the GraphQL server

yep

Isn't that very difficult to do because of the dynamic nature of it all?

use the query and variables as the query string.

[deinok]

I think that Apollo client does some kind of caching. The idea is take that, an port that system to here.

[deinok]

Also, there is two kind of caching: just client (no trips to server) and client-server (server notify the changes of the client-cache)

[SimonCropp]

Sorry. Ignore my comment. I was still in the context of the browser usage scenario

[vytautas-pranskunas-]

Hello,soalmost year passed ... any activity on this? Caching is very important thing as we all know :) Btw prerealease 2 is not released almost for a year (Sep 13, 2018) maybe we can hurry this up? Do not want to be forced to Swith to Apollo 2.6 :(

[sungam3r]

The most difficult part in this task is not so much caching as the creation of a hash value normalization function.

[b-jsshapiro]

One of the things that was learned in apollo-client is that generic object identities for a cache is application dependent. The _typename+id approach works very well to get started, and it seems to cover >95% of the cases. Once you get past that, you're going to have to let the application author have a voice in the outcome.

GraphQL has great strengths, but those strengths make it very difficult to leverage from a statically typed programming language (and anybody who looks me up on lambda-the-ultimate can see I'm firmly in favor of static typing). The problem, fundamentally, is that the ability to select fields in queries does not align with static typing in the cache. I've been scratching my head about this for a while. The best I've got so far is to precompile queries on the client side to create suitable interfaces and code-behind getters that are specific to each query, and then let the behavior in the cache be totally dynamic.

This would either mean giving up the idea of inline queries or doing some serious compile-time background processing to generate the corresponding C# code at compile time - either of which is doable.

I haven't looked at this library hard enough to see what approach it is taking, but that's what I'd try first. I like the NewtonSoft libraries, but getting back a JSON object in response to a query doesn't exactly put the client-side programmer in an easy position.

[vany0114]

Any update on the cache implementation?

[rose-a]

Hi, no, there is currently no work underway regarding this feature (at least from my side).