With only a query and an optional operationName, how to know to call resolve or subscribe?

[Sarcasm]

I get request with only query, operationName and variables, which I then need to feed to the proper service method: resolve for queries and mutations, and subscribe for subscriptions.

Is there any way to find what will be the effective "operation type"?
One of query, mutation or subscription (I'd like to distinguish mutations from queries as well).

[Sarcasm]

Some additional thoughts.

Maybe add a new method to get the operation AST, as well as its type, so that this information is not recomputed unnecessarily.
Make a new resolve() overload where the right operation AST can be specified directly, the old method could be implemented in terms of the new one:

enum class OperationType { Query, Mutation, Subscription };
const peg::ast_node& findOperationAndType(const peg::ast_node& root, const std::string& operationName, OperationType *operationType = nullptr) const;

std::future<response::Value> resolve(const std::shared_ptr<RequestState>& state, const peg::ast_node& operationNode, response::Value&& variables) const

std::future<response::Value> resolve(const std::shared_ptr<RequestState>& state, const peg::ast_node& root, const std::string& operationName, response::Value&& variables) const
{
  return resolve(state, findOperationAndType(root, operationName), variables);
}

Maybe the findOperationAndType could be shared between subscriptions and queries/mutations, right now the logic is a bit duplicated between SubscriptionDefinitionVisitor::visit() and OperationDefinitionVisitor::visit().

[wravery]

Subscriptions are always separate in the sense that you set them up with a callback for a continuous event stream rather than a single completion callback on the client side, it's just a matter of routing those calls to the correct API on the service::Request/schema::Operations object. In my projects I've been implementing the Relay Modern createSubscription (only used for subscriptions) and fetchQuery (used for queries and mutations) callbacks with calls to separate native module interfaces or websocket bindings instead of HTTP POST requests.

But I can see how knowing in a lower level resolver might be useful. For now you could augment the service::RequestState (with a sub-class) and add a member with that enum value, then set it in the root field accessors for each of the top level operations.

Longer term (ideally included in the upcoming v2.0 release) I think it would be simpler and it would make sense to add an enum member for the operation type to SelectionSetParams so it flows from service::Request::resolve or service::Request::deliver automatically in ResolverParams and FieldParams and it can be declared as const since it doesn't need to be changed in any of the resolvers once the struct is initialized.

[Sarcasm]

I'm not looking for this information in the resolver, what I want is to route a request defined by the set of parameters query, variables and operationName, to the correct method of the service, resolve or subscription?
And probably do some bookeeping with the subscription key additionally.

On the websocket protocol used for subscriptions, a single endpoint is capable of handling query, mutation and subscription.

We get messages like this for queries:

{
  "id":"1",
  "type":"start",
  "payload": {
    "query":"query {\n  time\n}",
    "variables": null,
    "operationName": null
  }
}

And for subscriptions:

{
  "id":"2",
  "type":"start",
  "payload": {
    "query":"subscription {\n  time(tick: SECONDS)\n}",
    "variables": null,
    "operationName": null
  }
}

[wravery]

How do you route the event stream for that subscription back to the sender?

[wravery]

Or do you mean that it all goes over a single websocket and you are able to correlate the messages coming back, i.e. with the id field?

[Sarcasm]

Yes, that's it.

[wravery]

OK, sounds like a useful feature. Building an OperationMap and exposing a method or function to access it seems like it would be more flexible.

Short term do you control the message format? You could distinguish between subscriptions and queries/mutations from the sender as a workaround, assuming you know at the call site where the message is constructed.

[Sarcasm]

Not sure to understand how one would use the OperationMap, if it is what I think.
I could be nice if the operationName is provided, but when no operation name is specified, how would I know the type of the operation in a single-operation document?

Short term do you control the message format?

Not really, the message format I showed is just the WebSocket protocol defined here:

• https://github.com/apollographql/subscriptions-transport-ws/blob/34d503a6cef99efaffb35dae6a816ab898440565/PROTOCOL.md

This is often referred as the transport for subscriptions, but it actually support all 3 sorts of operations, using the same start message type, and the same arguments in the same session.
So the server receiving the request has to know from the query and operationName inputs what to do.
Right now the sender is a GraphiQL with subscription support, so depending on what I type, I get different kinds of requests on the same WebSocket.
Typically I want to have a GraphiQL sending a mutation on a WebSocket, and another have a subscription on the same endpoint.

Anyway, as I'm just experimenting/prototyping things, I will find a workaround.

[Sarcasm]

Thank you!