Jacob Thomason

@oprypkhantc it'd be nice to see some action around this for sure. I agree that sticking with SSE and the HTTP protocol is more fitting for GraphQLite. Bi-directional communication over...

@oprypkhantc Something I'm unsure about is the return type of the subscription resolver. Currently we're using this for the output type and fields. We might be able to override this...

This really feels like it's being attacked from the wrong angle - almost like trying to shoehorn something into an existing design. An annotation for the return type is certainly...

So, there would be a global Subscriber service, which would implement our `SubscriberInterface`, that'd be registered with the GraphQLite config. Also, the `Subscription` attribute would take an optional `subscriber` argument...

To start, I'm not familiar with Redis' pub/sub design. So, I cannot speak to how Redis dispatches/notifies subscribers about a particular channel/message from a publisher. I assume each redis client...

So, I'd should mention that I'd like to see subscriptions support webhooks as well. That means, the assumption that a subscription is a long running process remains a userland implementation...

[From the specification on subscriptions](https://spec.graphql.org/June2018/#sec-Subscription): >Delivery Agnostic >GraphQL subscriptions do not require any specific serialization format or transport mechanism. Subscriptions specifies algorithms for the creation of a stream, the content...

>I'm not sure what you're referring to with the "correct subscription". In this case, a subscription is a long-lived request (and a long-lived process). Everything you yield from the controller...

The first one is certainly more desirable. I think this is all looking good now 👍. It's flexible enough for most any use case and the separation of logic looks...

Cool. So, something to keep in mind is that async PHP might not be the way many people choose to implement subscriptions. In fact, I'd argue that your subscriptions should...