First, the getting started example was incorrect and instructed users to
install the wrong package.
Furthermore, each integration example was duplicated on its individual
package `README.md` and the verbosity of this `README.md` (which is for the
entire monorepo) makes it unclear where to start.
This change points those who desire the integration approach to the specific
page which has more information about those integrations (and mostly the
same content in terms of examples which are listed here, albeit with subtle
variations.)
While it used to be required to pass the `--save` flag in order to actually
write the dependency to the project's `package.json` file, this is no longer
the case in recent versions of npm.
As we're moving the community from Slack to Spectrum, its time to update
these shields from our project README files (which show on npm and in
GitHub) to reflect the new home for conversation.
If you haven't already joined the new Apollo community on Spectrum.chat,
visit https://spectrum.chat/apollo/ to join the discussion!
For more details on the move, checkout the Apollo blog post by @hwillson:
https://blog.apollographql.com/goodbye-slack-hello-spectrum-8fa6b979645b
* 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