Giters

NavidK0 / SimpleGraphQL-For-Unity

A simple graphQL client that allows one to use .graphql files (or code) for queries, mutations, and subscriptions with Unity.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Problems when subscriptions complete

Sewdn opened this issue · comments

commented

Hi,

I was encountering issues when using multiple subscriptions in my application (using graphql-transport-ws subProtocol).
SimpleGraphQLClient is (by design) using a single Websocket instance for all running subscriptions.

However, when a running subscription is unsubscribed (the graphql server will handle this request with a stop/complete payload), the WebSocketUpdate breaks (https://github.com/LastAbyss/SimpleGraphQL-For-Unity/blob/master/Runtime/SimpleGraphQL/HttpUtils.cs#L368), and no further payloads are being processed anymore, so other subscriptions don't receive any updates.

I suggest to just continue the loop, when a subscription completes/ends. Or would this harm performance?
Another suggestion is to track the running subscriptions, and disconnect (dispose) the single web socket as soon as all subscriptions where unsubscribed again. When opening a new subscription afterwards, this would reopen a new connection, and restart the update cycle.

What do you think?

commented

I like your second solution to this problem. I think it's necessary to implement since we should implement the behavior for the stop payload on websocket disconnects as well.

WebSocketUpdate should only break when there are zero active subscriptions left, and I believe all we need is a simple counter that increments/decrements on the start/stop of subscriptions.

commented

I’ll submit a PR tomorrow to fix this, using a counter to represent active subscriptions and do a proper disconnect when no active subscriptions remain.

For the stop command, I don’t completely understand what you mean. Maybe this confusion relates to the difference in subprotocols. For graphql-transport-ws subprotocol there is no stop type payload, only a (bidirectional) complete: https://github.com/enisdenjo/graphql-ws/blob/master/PROTOCOL.md#complete

commented

I suppose I was going by your statement where you mention "stop/complete" payload:

However, when a running subscription is unsubscribed (the graphql server will handle this request with a stop/complete payload), the WebSocketUpdate breaks...(cont)

I saw that we submit a "stop" payload on non graphql-transport-ws, but don't check for it here:
https://github.com/LastAbyss/SimpleGraphQL-For-Unity/blob/1e987605ca452ec62dd142b36a26b8f208257819/Runtime/SimpleGraphQL/HttpUtils.cs#L365

Not sure if that's a problem for our use case (I haven't used this library in quite some time).

commented

I guess that the stop command (client->server) and complete (server->client) response are unidirectional in graphql-ws subprotocol, since I haven't changed the response payload processing when introducing graphql-transport-ws (https://github.com/LastAbyss/SimpleGraphQL-For-Unity/pull/37/files). But I can't seem to find any published info about this online...

commented

In that case, we're probably OK to move forward as is. I was just concerned that we might've forgotten something that would cause a bug later. I also searched for documentation on it, and it's pretty sparse... but I haven't seen anyone complain about it thus far, so I think it's alright to leave it alone.

Feel free to proceed with your PR as you wish, and I'll give it a look whenever you're ready!

commented

PR done! Please give it a look. Thx!
#43

commented

Gave it a look, looks great! Just needs a couple of edits and it should be good to go.

commented

Thanks a lot, Pieter! I appreciate your work on this! 😄