ApolloServer builds in graphql-playground rather than graphiql, so we no longer
provide middleware for serving GraphiQL.
If this turns out to be an unpopular choice, we can always add support for
graphiql instead of graphql-playground back in later.
We prefer graphql-playground because it allows you to enter HTTP request
headers, view query history, and explicitly supports graphql@0.13.
runQuery currently takes a `query` argument that is either a string or a
DocumentNode. This means that it's possible to accidentally support syntax we
don't mean to. For example, if you happen to send a JSON-serialized DocumentNode
over the wire, we'll happily execute that, and you'll believe you're using
GraphQL even though you really aren't --- until you try to use some other
GraphQL tool that expects to see the GraphQL query language rather than
graphql-js ASTs.
Additionally, GET requests parse their queries in runHttpQuery rather than
runQuery, leading to inconsistent error handling semantics on parse failures.
Simplify the runQuery API (which is technically exported though intended to be
mostly internal) to take in either a parsedQuery or a queryString argument. The
main use case for knowing about these parameters is if you're using formatParams
with OperationStore; its docs and tests have been updated to reflect this.
Stop parsing queries in runHttpQuery; instead, ensure we throw the right error
for mutations-over-GET by passing the error to throw into runQuery.
Stop accidentally supporting graphql-js ASTs on the wire --- but throw an
informative error when you do so.
This backwards-incompatible change is intended for apollo-server-core 2.0.
