proposal: graphql integration #35
Description
Ripple keeps nodes (clients/servers) in sync by replicating an immutable log of actions in the background, and subsequently reactively updating other modules (like the view) when the local store is updated (see pic). The current value of a resource is given by reducing all the change objects from time 0. Each mutation actually results in a new state, so clients do not need to store the entire log unless for debugging.
It's currently possible to retrieve either a named resource (users), or a subresource using the dot notation (users.mike.name). The properties can be links across resources too (users.mike.friends.jane).
I think it should also be possible to decompose/flatten a GraphQL query into it's constituent parts. This will allow the core/sync modules to dedupe across multiple requests for the entire application, and use the existing backpressure to keep the local cache always in sync so components will still be realtime and there will be no over-fetching (i.e. optimisations like if a page needs a.b.c and a.b, requesting a.b would be sufficient).
GraphQL would be a convenient format for components to specify the data they require in, but separated from the concern of loading/batching/synchronising under the hood.
/cc @leeb @rauchg @sammyt for any thoughts on this approach, whether it's possible/desirable/can be improved..
I think the only thing that is missing is being able to parameterise each property, perhaps something like users({ name: 'mike' }).friends?
