Client provider subscription support#235
Client provider subscription support#235ivelten wants to merge 2 commits intofsprojects:devfrom ivelten:tp-provider-subs-2
Conversation
| member __.Dispose() = unsubscriber () |> Async.RunSynchronously | ||
|
|
||
| /// An interface for implementing subscription handlers for GraphQLProvider. | ||
| type IGraphQLSubscriptionHandler = |
There was a problem hiding this comment.
This is a standard interface for implementing subscription handlers, in case the client code does not use the GraphQL Over Web Socket spec that we default to.
|
|
||
| /// A GraphQL subscription handler which uses GraphQL Over Web Socket protocol. | ||
| /// See https://github.com/apollographql/subscriptions-transport-ws/blob/master/PROTOCOL.md for information. | ||
| type GraphQLOverWebSocketSubscriptionHandler() = |
There was a problem hiding this comment.
This is the default implementation of the handler, which uses the spec we default to. The idea is to share it with each subscription call of the provider because this connection can be reused like the classical HTTP connection.
| |> Seq.iter (function | ||
| | Incoming payload -> observer.OnNext(payload) | ||
| | Finished -> observer.OnCompleted()) | ||
| { new IDisposable with member __.Dispose() = () } } |
There was a problem hiding this comment.
We pick the first item from the response and use it as the direct result.
The remaining items will be processed into the deferred result as an IObservable.
Every Observable returns JsonValue here. They will be mapped into provided types in the ProvidedTypesHelper.
| member __.AsyncUnsubscribe() = unsubscriber () | ||
|
|
||
| interface IDisposable with | ||
| member __.Dispose() = unsubscriber () |> Async.RunSynchronously |
There was a problem hiding this comment.
Unsubscriber, in this case, will send a message to the server to end the connection (Stop <id>). When the server responds with Complete <id>, it will be processed in the observable above and call OnComplete to properly end the observer subscription.
|
Is it already implemented in the client? |
|
@valbers I think we need to extract your server-side models, JSON serializer and common logic (if applicable) to a separate project |
|
Just for the record: the changes in this PR are based on the superseded websockets subprotocol |
3 participants
With this PR, I am proposing a subscription interface for the client provider.
The proposal specifies that we should try to be most agnostic possible from subscription protocols, in case the client code needs to connect to a custom implementation. We offer this spec as the default one, in case no one is provided, though.