Combine `subscribe` with `execute`?

Right now, subscribe and execute are two functions. And there are some issues with that.

1. Semantically, subscription is a type of execution. In the spec, Query, Mutation and Subscription are on the same level. Subscription is not an outlier.
2. When I get a Document, I need to go through validations to get the Operation, and then call execute or subscribe based on Operation’s type, and they go through a similar validation, resulting in duplicated work.

[jasonkuhrt]

Just happened this use-case. As a user, my initial expectation was that I would be able to do query.execute. I was initially surprised to learn that subscription was a separate method.

But I sympathize with how the polymorphic type this would result in could hurt DX.

A new TS generic parameter and/or casting could do their bit to help, but only modestly.

Most of the time, in practice, what would probably happen, is users narrowing the result before using it.

In the end, having the API allow to do this branching up front (method selection vs result narrowing) seems very reasonable.

I don’t see a “best” option here. Maybe both, e.g.:

graphql.execute(...) // ExecutionResult | Promise<AsyncIterator<ExecutionResult>
graphql.executeSubscription() // Promise<AsyncIterator<ExecutionResult>
graphql.executeQuery() // ExecutionResult
graphql.executeMutation() // ExecutionResult

I don’t know if splitting Query / Mutation for API symmetry has any functional benefit here. Maybe that’s acceptable, not sure.

[ericls]

@IvanGoncharov , thanks again for you reply.

buildExecutionContext is indeed very helpful. I think I’ll use it for now.