Playground can either use external settings or its default settings (browser settings), in incompatible ways. The original implementation of default settings here would always provide 'settings' for Playground, in turn make its own settings mechanism disabled, with consequences such as altering settings in-browser cannot work as expect. Besides, once the default settings here go different with Playground provided, it would cause other problems.
The intention here is to use Playground setting as default, while explicit passing Playground settings in Apollo server would still work with defaults defined here merged.
* Initial implementation of Apollo Server 2 for gcf
* First try at running with tests
* Updated naming
* Removed lambda mentions
* Simply use referer
* Updated README
* Updated Changelog
* Renamed gqlApollo to googleCloudApollo
* Added more details
* Removed extra check
* Pass payload into the context function for subscriptions
The payload can be used for things like auth. You can pass a token on
the payload of the message and use it to fetch the user.
* Update CHANGELOG.md
* Fixed support for GraphQL Playground with custom configuration in production environments.
* Updated logic in `createPlaygroundOptions` to cast the `playground` option to a boolean
if it is defined. Fall back to `isDev` logic only if undefined.
* Updated unit test for partial graphql playground options to emulate a 'production'
environment, mimicking the scenario that was broken before.
* Add PR #1495 to CHANGELOG.
* Restore partial playground options test when no `NODE_ENV`
* Initial revision
* Ensure dist directory exists
* Add envrc for direnv users.
* protobufjs is a runtime dependency
* 0.0.0-beta.2
* update reports.proto with FullTracesReport
* 0.0.0-beta.3
* depend on @types/long
* 0.0.0-beta.4
* instead, do not use long
* 0.0.0-beta.5
* Add Details.variablesJson
* 0.0.0-beta.6
* comment-only update to new field
* 0.0.0-beta.7
* update a-e-reporting readme to reflect production ready state
* update changelog the engine reporting
* reporting-protobuf: prepare -> prepublish
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.
* Added fixes to apolloAzureFunctions.js and sample functions for the GraphQL API and GraphiQL
* Added issue and pr details to changelog
* Maintain use of `context.done()`, but use `isRaw` instead.
Per the Azure documentation regarding the response object available at:
https://docs.microsoft.com/en-us/azure/azure-functions/functions-reference-node#response-object
* Switch Azure example to use CommonJS rather than native ESM exports.
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.
* Export `GraphQLOptions` type directly from `apollo-server-express`.
Directly export `GraphQLOptions` from the `apollo-server-express` (and
synonymously, `graphql-server-express`) main module, rather than exporting
it only from `./expressApollo`.
This fixes the default behavior for class-based contexts by also cloning the prototype, and it allows you to customize per-operation behavior by passing in a function as context.
