Decouple GraphQL store with a generic API

I think it might be kinda cool to provide some sort of interface similarly to how we do it with NetworkInterface.

Redux could be the “default” but excludable, and users could plug in mobx or reflux or whatever.

If the interface implements async functions, the store could even be run in something like redis (for server side caching, for instance, for inter-service RPC) or a web worker to reduce the number of state change cycles on the main thread.

I think it might be worth exploring. Doesn’t seem like it would add much cost other than initial dev time to establish an interface. After that it would likely result in better code even within the internal lib, since there would be a well-enforced contract with how apollo-client couples itself to the implemented caching mechanism.

Wondering what other people think about this idea @stubailo @helfer

[emcpadden]

Looking forward to an integration with ngRX. I am using ngRX already and really love it, it feels like the right redux-style store for Angular apps. I am just starting to look at graphQL/apollo and would love to have a clean integration between the two. It would be a great bridge for adoption for Angular users that want to stay close to Angular projects like ngRX.

[helfer]

Yes, this is still on our radar. We’re also trying to make sure it’s aligned with iOS and Android, so it’s probably going to take another week or two until we put a more complete draft out there. Our latest blog post contains a very high-level overview though.