Please make subscription value structure consistent with query value structure

So imagine the following basic schema:

type Query {
  foo(tag: String): MetadataItem
}

type Subscription {
  foo(tag: String): MetadataItem
}

My resolver for Query.foo can return a Promise<MetadataItem>. You would think my subscribe resolver could return an AsyncIterable<MetadataItem>. But noooo… For whatever reason it has to return an AsyncIterable<{foo: MetadataItem}>. Why do I have to wrap the values I yield in an object? Is there a good reason for this or is it just a mistake?

This is really annoying and it always trips me up. Why were subscriptions designed this way instead of being more consistent with queries? I feel very angry about how often I have had to debug issues stemming from this, because it’s just not an intuitive inconsistency. It’s very easy to forget about.

GraphQL could so easily wrap the values I yield in an object with the field name, the only reason I can imagine that it doesn’t is some performance nitpick.

[IvanGoncharov]

@jedwards1211 It’s actually very consistent with query if you have the right mental model. You yield root value for the entire query (not just for foo field) and then it executing exactly the same as a query: http://facebook.github.io/graphql/June2018/#ExecuteSubscriptionEvent()

Actually, it’s so consistent with a query that if you register resolve on Subscription.foo it would be called with the value you yielded from your stream.

[jedwards1211]

@IvanGoncharov I still find this terribly confusing.

Although this doesn’t seem to the behavior described in the spec, from what I’m observing with running code, it appears that:

• If subscribe has a sibling resolve function, then subscribe can yield just the value of its field without any wrapper object?
• Otherwise subscribe has to yield an object corresponding to the shape of the Subscription type

I am using Apollo’s buildExecutableSchema so maybe the confusion’s coming from there…