Subscription analogue to share changes on client to the server

[ghost]

Hello.

As I understand, currently GraphQL has no any mechanism to make accumulated client changes continuously shared to the server in streaming way, like current subscription implementation, but vice-versa?

Can someone suggest the answer?

[benjie]

GraphQL is independent of transport, so you can use websockets or similar as a realtime two-way transport. You can then issue regular GraphQL mutation operations over this transport every time the client makes changes. What difference would your proposal have over this?

[ghost]

We can use regular queries, but we have subscription semantics. My thought was to form a question, does a concept with reverse reasoning exists.

If client can subscribe to server changes, why there is no developed semantics to push accumulated changes to the server?

If subscription helps to automate streaming model changes from backend, why not represent a client as a graphql API from server point of view?

[benjie]

In this case you'd be turning the client into a server and having what was the server subscribe to changes on what was the client. Since GraphQL is transport agnostic you could potentially do exactly that - you could issue a mutation from the client to the server instructing the server to subscribe to the client, then the server could issue a subscription request to the client (using the client's GraphQL schema based on the operations that it supports) and consume those subscription events however it sees fit.