* koa integration
* use koa-bodyparser v3 for node 6 support
* use middlewareFromPath instead of koa-router
* use async/await in koa fileUploadMiddleware
* 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
* initial implementation of aws lambda integration for apollo server 2
* ApolloServer class
* package.json cleanup
* parse json of body
* createHandler function, complete README
* cors options
* update readme
* lambdaApollo tests
* fix tests
* Enable declarationMap in tsconfig.json
See http://www.typescriptlang.org/docs/handbook/release-notes/typescript-2-9.html
* Add apollo-server-caching package and improve typings
* Remove superfluous test steps
* Add .npmignore to apollo-server-caching
* Add apollo-server-env and apollo-datasource-rest packages
* Fix broken imports
* Use prepublish instead of prepare
* cache is now passed to data sources from ApolloServer constructor
* fix Object.values to use the object passed in rather than this
* add initial datasource test
* docs: initial data source documentation
* docs: initial data source documentation
* compiles and documentation now highlights code in data-sources.md
* Some changes to the data source 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.
The express-graphql reference implementation [provides a check]
(2e27a73358/src/index.js (L201-L208))
to protect against cases where a GET request is made that does not
have a `query` parameter where the GraphQL query would be present.
Without this guard, graphql-js's `parse` will return `undefined`
for the `DocumentNode` since it has no document to read. Subsequently
passing this to `isQueryOperation` results in a `TypeError`, because
we are providing `undefined` where `getOperationAst` [expects to get
a DocumentNode](5fe39262a3/src/utilities/getOperationAST.js (L19)).
A new test file is added for `runHttpQuery`, as one previously did
not seem to exist.
* micro is only supported in node 6 or greater
* update dependencies
* working Graphiql Server
* updated changelog
* fix linting errors
* adding micro to test suite
* added micro example
Newer versions of Koa use features of ES6 that are not supported in
nodejs v4. This commits enables the Koa integration test only when run
on nodejs v6 or newer.
Create an integration that will return a lambda handler for a
graphql or graphiql server. This integration requires an API
Gateway with Lambda Proxy Integration.
The test runner expects req and res objects for testing. We
have to mock these for the tests to execute properly.
