In an effort to maintain consistency and semantically correct meaning,
this changes (only in documentation and internal Apollo Server tests) the
name of the first argument in resolver signatures to use `parent` rather
than `root`.
While `root` certainly makes sense when the resolver is belonging to the
root `Query` or `Mutation` type, once nested field resolvers begin getting
called, the more semantically correct term would seem to be `parent`.
Since `parent` still makes sense at the root level, and since resolvers
frequently get copied and pasted into more deeply-nested positions, putting
this pattern in place for apps which are just beginning might just help
someone more clearly understand the relationship in the future — without
incorrectly thinking that a nested resolver is accessing the root of the
graph, rather than the parent.
* Initial basic Micro integration
* Wire up health check capabilities
* Add playground support; Refactoring
* Add custom path support
* Add file upload support
* Add subscription support
* Documentation and formatting updates
* Wire up tests
* Add Node 10 workaround for file upload testing
* Code review changes (docs, naming, formatting)
* Adjust exports to line up with other integrations
* micro: add graphql to npm install and lines to highlight in docs
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.
There were many missing releases and bullet points as well as inaccurate
ones. For example, it was impossible to figure out that users of Hapi 16 who
want to use Apollo Cache Control needed to use precisely version 1.2.0 of
apollo-server-hapi (which wasn't even mentioned).
Link to CHANGELOG from all READMEs. Add READMEs for the graphql-server-*
packages. Add an explanation of our versioning system to the top of
CHANGELOG.md.
* 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