[Discussion] - Real-time data in Relay using the Mutations API

[zuhair-naqvi]

The community has discussed many potential approaches to handling push data with Relay. One of the more complex aspects of this problem seems to be the fact that a change in data can have multiple / varying effects on the UI. Think the like count problem. While this is addressed by mutations in a synchronous request-response model, there isn't a lot of clarity around how subscriptions will fit in.

One approach I've been thinking of is to use the mutations API to achieve this but I wanted to get some feedback to make sure it's not a completely crazy idea.

Here goes: Given any change in the graph is essentially a mutation, what if GraphQL published the payload (along with meta-data about the client side mutation) to a pub-sub service in addition to returning the payload to the original client?

When a subscriber receives a message with the mutation payload, it can call Relay.commitUpdate with a localPayload prop which will tell your custom network layer to skip the network request and resolve the mutation locally with the payload received from the pub-sub service.

High level architecture:

The benefits of this approach could be (assuming I'm not missing any major complexities):

1. You can implement this today with the existing APIs.
2. Your components already understand how to deal with incoming data i.e. no changes to your Relay.QL fragments unlike having a special Subscriptions construct.
3. The solution is opaque as far as Relay AND your components are concerned and you're not messing with Relay internals.

Some cons I can think of:

1. Only GraphQL can publish as the payload will always need to be in a shape that the client-side mutation understands (not necessarily a bad thing)
2. Not entirely sure if and how this will impact relay's internal cache, tracked queries, queuing etc.

Would be great to get your feedback on whether this is an avenue worth pursuing!

[josephsavona]

Yup! At a high level, what you're describing is the approach that we are pursuing with GraphQL subscriptions. Relay is designed to process subscription payloads the same as mutation payloads: given the mutation/subscription query, config, and payload, it correctly updates the cache and notifies affected components.

I wrote a brief note about how to implement real-time updates today using (mostly-public) APIs. Basically, your server can push mutation payloads to the client, and you can manually apply them to the store. I'd encourage you to try out this approach and let us know how it works.

Also see #559, which has more context on how we're thinking about the future of the API: more low-level primitives that you can use in different ways.

[josephsavona]

re the "cons":

• any approach would involve the server generating data, so the first con is more of a natural aspect of a push architecture
• as I mentioned, Relay can process subscriptions just like mutations, so everything that you can do with mutations will also work here (and limitations of the mutations API also apply, such as being able to append/prepend/remove items on ranges)

[zuhair-naqvi]

Thanks for the clarification @josephsavona! If the subscription API is the same as the mutation API, then why a separate Subscription Type just for the sake of it? Why not something like Relay.Store.commitUpdateLocal(Mutation, Payload)? This way, you can reuse your mutations when data is pushed from the server as well as support client state if you wanted to right?

[josephsavona]

Closing as this is possible today, and will be covered by #559: we're working toward a new core API that will allow "writing" data to the local store.