Subscriptions Implementation

[oojacoboo]

Hey and thanks for this great lib. I'm a maintainer for GraphQLite. We're taking a look at a subscriptions implementation and I have some questions. Firstly, I should state that we're hoping to achieve subscriptions support for both offloading and long-running stream support on the initial request and PHP process. That actually doesn't make much difference to webonyx, but want to frame the conversation accordingly.

As I've dug more into a possible implementation, I'm running into some roadblocks. Some of this is due to GraphQLite's design. But it more comes down to the schema compilation vs runtime considerations. Nonetheless, consider the following:

You have a request that comes in for a subscription, you may need to register/persist this request data, or possibly just directly setup the stream and keep the connection open (SSE, WS, etc). All of that is fine, and not a huge consideration for this library. However, the challenge begins to presents itself when evaluating what to persist/store in terms of the request/AST/GQL/variables/output fields/etc. This part is all workable, albeit not great. The issue is with the execution of what's been stored, at a later point, when publishing for a subscription.

Regardless of whether you're in a long running PHP process/stream with the data in memory, or you've persisted this data, or offloaded it to another service/node; you're presented with the issue of how to continually generate output fields/data based on whatever was stored for the subscription/request. For instance, when setting up a subscription, the defined output fields are describing the intended return data graph from the subscription stream, for each publishing. That means you need to be able to continually resolve these fields of an output type, over and over again.

I've taken a look at the GraphQL::executeQuery function, which might allow for this continual resolution of an operation/query, however, executing the input fields and the full query really isn't ideal. Typically a subscription is tied to an event system, where there is a target entity being published/sent. The subscription operation/resolver, isn't aware of the payload you'd need to handle for the output. You could possibly pass the subscription AST with input fields and all, then override the resolver, but I haven't found a good way to generate a custom resolver for this case. It's also kind of nasty.

Another function, Executor::execute seems like it could work. However, there doesn't seem to be a clear way to go from a type (PHP object representation), to a DocumentNode, assuming that's all that's needed, along with the schema to get the resulting output graph data.

So, I'm kind of left in this place where I don't see a clean way to actually implement subscriptions. Is anyone actually using subscriptions with this library? Are there any reference implementations?

[oojacoboo]

@vladar any ideas here?