Decouple GraphQL store with a generic API

[thebigredgeek]

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

[thebigredgeek]

Can we get discussion going on this? I'd love to drill down to design details once everyone is on board with it.

[helfer]

@thebigredgeek We've been planning this for a while and we think the interface should be quite similar to how the data proxy works.

Making the store reading asynchronous and Redux optional is going to be a pretty large breaking change. Our priority at the moment is 1.0, so this will have to wait until after that.

[ghost]

@helfer I see that 1.1.1 is out. Is this RFC still being considered? Thank you.

[smolinari]

I'm also interested in this!

Scott

[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.

[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.

[petercn]

@helfer Any recent updates on this?

[kokjinsam]

I recently made a comment on another issue regarding Apollo and web worker implementation. Please feel free to give feedback on that

[stubailo]

@shadaj can you provide a longer update on what you're working on?

The first few PRs in this direction are #1845 and #1846 and #1859

[shadaj]

Sure, I'm going to be working on implementing a new store API that will make it possible to plug in different backing store implementations into Apollo. The first step of this is to extract out the Redux implementation of the Apollo store into a separate module, where we can place it under a more general API. The new Store API will make it possible to provide custom implementations of Apollo stores with custom caching logic, and we are also exploring the possibility of simply plugging in a key-value backing store and layering existing Apollo store logic on top of that.

Right now, I'm working on migrating some state (such as query and mutation status) from Redux into their own state trackers, which will make it easier later on to extract out the entire Apollo store implementation into a separate module.

[avatsaev]

I wanted to use apollo in our newest angular project, but not being able to use it with ngrx/store, ngrx/effects is kind of a deal breaker.

[stubailo]

First steps here: #1921

[amitport]

(#1921 is merged)

[avatsaev]

Will there an update of the official doc with angular ngrx integration or maybe update the current tutorial to use ngrx by default instead of redux? Considering ngrx is pretty much the official state management lib for Angular apps: https://blog.angular.io/announcing-ngrx-4-87df0eaa2806

[cport1]

You can use ngrx alongside apollo-client just fine .. there are a dozen other conversations about turning off the cache .. there's also apollo fetch and apollo link

https://github.com/apollographql/apollo-fetch

[stale]

This issue has been automatically marked as stale becuase it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions to Apollo Client!

[val-samonte]

Sorry for the annoyance, but is this something that will be out on the next major release?

[stale]

This issue has been automatically marked as stale becuase it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions to Apollo Client!

[hccampos]

Any news on this? Marked as stale but I can't find more info regarding a solution/etc.

[stubailo]

Yep, this is part of the Apollo Client 2.0 work!

Here's the cache API to implement:

apollo-client/packages/apollo-cache/src/cache.ts

Line 8 in 14a7bc4

export abstract class ApolloCache<TSerialized> implements DataProxy {

Here are two implementations:

1. In memory cache similar to Apollo Client 1.0: https://github.com/apollographql/apollo-client/tree/14a7bc4ff7e87c3f99844a79538029939c9cd0cf/packages/apollo-cache-inmemory
2. Hermes, written by some people from Convoy: https://github.com/convoyinc/apollo-cache-hermes

It's still early days but AC 2.0 just entered beta, so we're going to be working on a lot of documentation for all of this stuff.

You can read more about it in this post as well: https://dev-blog.apollodata.com/whats-coming-in-apollo-client-2-0-bcd8ea64acbd

[tlvenn]

Is there any collaboration with Relay team regarding the cache API ? At some point if it becomes pluggable in Relay Modern as well, it would be neat if implementations could work in both libs.

Just pondering...

[nevir]

Hermes is built in a way that it could be pretty easily adapted for other clients - but, honestly, given how tightly coupled Relay's API is with its cache (particularly all the precompilation work), it would be unlikely that Relay could support alternate cache implementations

Apollo's Cache API is pretty clean, too

[stubailo]

Yeah it could be a cool hackathon project to try to jam together the Relay cache with Apollo's API/networking. Although I hope that this new feature enables people to innovate quickly on new cache implementations, so we have enough options to choose from even without that!

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions to Apollo Client!

[changalberto]

Not stale you salty bot! =)

[jbaxleyiii]

This is done the 2.0 🎉

[fxck]

Are there any examples (of the ngrx integration)?

[BhaskaranR]

@fxck i was able to make it work with this ngrx branch, not sure why this is not released yet.
https://github.com/apollographql/apollo-angular/tree/1.0-ngrx

[Timopheym]

And what about Mobx store? Is there some example too? Pleas!

[jeremyputeaux]

@kamilkisiela just released https://github.com/apollographql/apollo-angular/tree/1.0-ngrx/packages/apollo-angular-cache-ngrx
Here is a stackblitz https://stackblitz.com/edit/apollo-angular-ngrx

[simonpeters]

@jeremyputeaux cool! nice work.

How would you combine state data with an apollo query? With a filter for example.