graphql.github.io | GraphQL Documentation at graphql.org | GraphQL library

(Copying response from issue)

Actually, I think that it is valid. The spec says :

• If selectionType is an interface, union, or object

The subselection set of that selection must NOT BE empty

It simply states that it must contain a subselection (could be an inline fragment as in your example). It doesn't specify that its subselections must be leaf field selections.

I agree that in essence it should actually contain leaf selections for every possible subtype of the field's return type (e.g Human and Droid in your scenario), otherwise it could return an empty response. For instance, if there are no humans and 3 droids in your database then it would return:

A document is really any string containing valid GraphQL syntax. According to the spec, a document contains one or more definitions, where a definition could be:

an operation definition

Unlike types, the SchemaDefinition spec does not contain a Description. The __Schema introspection type also does not have a description field. So there is no way to set or get a description for the entire schema.

It is, however, an upcoming feature.

This behavior has not changed in version 2. Apollo Server produces spec-compliant responses and does not not wrap any resulting errors in an error object. Instead, this is just a known bug with GraphQL Playground. With version 2.0, Apollo Server transition from GraphiQL to GraphQL Playground. GraphiQL did not have this same issue, which is why this looks like a bug with Apollo Server. Check the network tab and look at the actual response from your server -- it's actually in the expected format.

No, there is nothing incorrect about your approach. The GraphQL spec allows any field to have an argument and allows any argument to accept an Input Object Type, regardless of the operation. In fact, the differences between a query and a mutation are largely symbolic.

It's worth pointing out that any field can accept an argument -- not just ones at the root level. So if it suited your needs, you could easily set up a schema that would allow queries like:

Note that name is still specified on Starship because otherwise it wouldn't show up in the results given that Starship is not a Character!

That simply means that because we are using a Union type, given two types that are part of the Union that both have a name field, you still have to request the name field for each type in their inline fragment. Omitting the name for the Starship fragment, but including it on Character, means if the returned type is a Character the name field will be present but it will not be present on the Starship type.

The docs are mentioning this to highlight the difference between Unions and Interfaces. If SearchResult was an Interface that included the name field and Character and Starship implemented that Interface, you could do something like this instead:

Devices with less than 640px width will zoom out the content (if you set initial-scale=1 then devices won't zoom it out and you have horizontal scroll).

It looks good on mobile but it looks small and you have to zoom in to read some texts.

The advantage is that you don't need to design your site for resolutions below 640px, but the tradeoff is that users have to zoom in.

if you want to test a query in a lifecycle method I would use the higher order component "withApollo"

#withApollo