Fork me on GitHub
#graphql
<
2017-06-13
>
hlship21:06:39

Looking for feedback on Subscriptions before make a pass at implementing them. https://github.com/walmartlabs/lacinia/issues/78 This will be partly in Lacinia, and completed in lacinia-pedestal.

dominicm22:06:05

hlship: > an asynchronous process is started Does this imply a thread will be started to run the call back?

hlship22:06:22

No. The intent is that the subscription is responsible for starting a thread or otherwise obtaining the stream of values, and must invoke the provided callback with each value. I'll update the text to make this more clear. It was just rough notes.

mpenet03:06:50

What about flow control/backpressure? How do we know if we have a slow consumer for instance

stijn06:06:41

how can a consumer cancel a subscription?

hlship16:06:14

@stjin: each subscription is a new request, with an open-ended response. The consumer can simply close the HTTP pipe on their end.

hlship16:06:44

Pedestal will supply most of what's needed.

hlship16:06:45

In terms of back-pressure, I'm not sure exactly. You can imagine inserting a lossy channel between the subscriptions' event callback and the CSP that does the rendering of each event.

stijn17:06:41

and if you're not using pedestal? what is the lacinia interface for cancelling the subscription?

mpenet19:06:26

Lossy is not good imho (sometimes you just cant), there should be a way to signal backpressure upsteam (from your http handler for instance)

mpenet19:06:16

Or this should be optional/pluggable

hlship18:06:31

The contract for this in lacinia proper is wholly functional; the implementation in lacinia-pedestal will be an interceptor that can be replaced.

mpenet19:06:26

Lossy is not good imho (sometimes you just cant), there should be a way to signal backpressure upsteam (from your http handler for instance)