Relay Cache with Flux Pattern?

[ccorcos]

I'd really like to incorporate the Relay cache within my Flux store so I can do "time-travel" and gain deep insight into the application. It looks like the store and the actions are classes which arent serializable :( but it looks like I ought to be able to separate the cache from the network requests and save the cache in a Flux store. Does that sound interesting or am I barking up the wrong tree?

[dminkovsky]

Been interested in this for a while! Would be great.

[ccorcos]

Have you heard of Datomic or Datascript -- its pretty interesting. It makes the whole caching side of things trivial at the expense of more computation.

[josephsavona]

Thanks for your question! I do have an answer for you, but we're trying to keep GitHub issues focused on tracking bugs and enhancements to help keep the signal high for contributors.

Would you mind posting your question to Stack Overflow with the #relayjs tag (or use that link)? If you post a link to your question here we'll be happy to answer - if the community doesn't beat us to it!

[ccorcos]

Sounds good @josephsavona

http://stackoverflow.com/questions/34409268/relay-cache-with-flux-pattern

[skosch]

@josephsavona I'd love an answer to this too, please do respond – I've been looking at http://github.com/gyzerok/adrenaline for this exact purpose, but I don't think it's quite up to snuff yet.

[ccorcos]

yeah, seems a little too hacky.

[josephsavona]

@skosch @ccorcos @dminkovsky I answered on Stack Overflow.

[skosch]

Thanks!

I suppose live queries of some sort would be necessary to make this work, but it would be nice – for my niche use case at least – if the clients could store not just the current data coming from the server, but also keep a history (i.e. Redux store) of all data changes that ever came down. In other words, I'd love a system that is

• realtime,
• makes optimistic UI updating easy
• supports GraphQL-based component data requirements,
• and allows for time travel through a (Relay and local) state store on the client, such that clients can undo whatever just happened (and when they do, that's another mutation that gets sent to the server, etc., keeping everyone and everything in sync with the DB on the server)

I realize these are somewhat muddy and even contradictory requirements, but I do wonder if there's some way (based around immutability and GraphQL) to make this happen, preferably without intercepting requests and keeping multiple copies of data around.

[josephsavona]

@skosch What you're describing matches up with our goals for Relay at a high-level. For example, we support optimistic UI updates out of the box, and real-time updates are on the roadmap (#541).

and allows for time travel through a (Relay and local) state store on the client, such that clients can undo whatever just happened (and when they do, that's another mutation that gets sent to the server, etc., keeping everyone and everything in sync with the DB on the server)

We'd definitely like to work with the community to support local state and to make debugging easier and more powerful (see #114, #541, etc). Some of the main challenges to implementing your idea as-is are correctness and performance. For example, in practice not all mutations have an easily calculated inverse operation. Further, other users may make changes in between a client committing and undoing a mutation such that it can't even be undone - ultimately, an app is really a client in a distributed system. As for performance, we have to be careful that the changes necessary to support advanced developer tools don't negatively affect the production performance of applications.

Keep the ideas coming, and I encourage you to take a look at Thinking in GraphQL if you haven't yet - it helps explain some of the architectural choices - and get involved with one of the help wanted issues.

[skosch]

Thanks for the kind reply and the links to #541 and #114. I knew about those threads but hadn't kept up with them.

I'm not interested in time travel as an "advanced developer tool" a.k.a. debugging toy, but as a clean way to provide end user undo functionality in data-based apps (read: lots of big but boring trees and tables of stuff) – i.e. what Google Docs provides for text files and spreadsheets. Of course, that means that every participant in the distributed system (whether client or server) needs their own version of the schema specifying how changes are to be applied and how data is to be resolved. I now see that this is already being worked on (https://github.com/eyston/relay-composite-network-layer) ... yay!

That kind of use case – a few dozens of users editing a tree of data together ­– is significantly different from and probably more common than Facebook's, where thousands of users tinker with insanely complex graphs of comments and likes and their associated subscriptions. And my intuition (which has been wrong before) says that in the former case, a more fully synched system with a shared history is possible and practically feasible, and client stores can be mutation reducers, and non-conflicting mutations could be undone independently, latency problems notwithstanding.

If we can come up with a more rigorous abstraction of how Google Docs is different from Facebook (e.g. what an inversible mutation must look like), then maybe we can let devs say "these queries/mutations here are self-contained and should behave in a shared, real-time and composable fashion", at their own risk of course.

[I hope I'm not wasting your time with this high-level babble. It's high time I looked into the Relay code myself and experimented a bit, I just haven't found the time yet.]