* docs: add koa example since it is in the github title
* fix: correct mistake
* Revert "fix: correct mistake"
This reverts commit 1de53f7e2b36c9ac7364a7f291f79bef4f77d777.
* fix: correct mistake
* Update README.md examples.
Follows-up on #1780 by fixing mismatching `port`s in the Koa example and switching other examples to be more DRY with regards to the `port` values.
Previously, we were planning to offer two kinds of APIs in "Apollo Server 2":
middleware functions just like in 1.0, and the new ApolloServer class. We have
not yet implemented ApolloServer for all of our supported web frameworks, so
this meant that the 2.0 version of modules such as apollo-server-koa (which does
not yet have an ApolloServer class) offered very little benefits over
apollo-server-koa@1.0 (as most of the benefits of 2.0 come from ApolloServer).
This is confusing. We are going to improve the current registerServer API so
that there's no real benefit to using a separately-exported middleware directly
rather than creating an ApolloServer and applying it to your web framework. So
the AS 2.0 API will just be ApolloServer. This means it doesn't make sense for
us to publish 2.x versions of the packages that don't yet support this API.
So this commit removes support for the following web frameworks: Adonis, Azure
Functions, Koa, Lambda, Micro, and Restify. (We leave in place Express, Hapi,
and Cloudflare workers.)
This isn't because we don't like these frameworks and don't want them to work
with Apollo Server 2.0! We would love to see each package resurrected and an
ApolloServer implementation built, either during this current 2.x beta phase or
after the official 2.0 release. Deleting these packages for now makes it more
clear which frameworks support 2.0 and which don't, rather than existing in a
state where apollo-server-express@2 has ApolloServer and apollo-server-koa@2
does not.
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.
* Add 1.0 migration article, belated
* Add tracing + cache control to sidebar
* Suggest graphql-tools
* Link to graphql-tools in README
* Wording
* Try a new title
* Add example to top
* Freshen up title page
* Improve homepage further
* File a PR!
* Try adding express README to sidebar
* Add READMEs to docs
* Add example page, overhaul setup
* More stuff
* Fix all old URLs
* Eliminate all mentions of graphql-server
* Fix azure functions shit
It is my understanding that `POST` to `/graphiql` will never occur since GraphiQL will talk to `/graphql` directly. Since this is not needed we may want to remove it to avoid confusion.
