Small documentation fix - coming across the phrase "encrypted WSS socket" and it's a bit odd when you're mentally expanding it to: "encrypted web socket secure socket"
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.
Hey guys,
I've noticed that some of the gql examples are indented differently than the rest and I think that consistent indentation and formatting makes it easier to read and comprehend.
Let me know what you think, thanks.
Due to changes in the third-party `graphql-upload` package which Apollo
Server utilizes to implement out-of-the-box file upload functionality, we
must drop support for file uploads in versions of the Node.js engine prior
to v8.5.0. Since file uploads are supported by default in Apollo Server 2.x,
and there is an explicit dependency on `graphql-upload`, we must
prevent users who are affected by this mid-major-release deprecation by
being surprised by the sudden lack of upload support.
By `throw`-ing an error at server startup for affected users, we certainly
are breaking a semantic versioning agreement for these users, however with a
relatively simple ergonomic (setting `uploads: false`) we allow those users
who are NOT utilizing file uploads (as we believe is the case with a
majority) to continue using their version of Node.js until it reaches the
end of its supported lifetime (as dictated by its Long Term Support
agreement with the Node.js Foundation). If we did not `throw` the error at
server start-up, those affected may not notice since they may update and start
their updated server without noticing the impending chance of failure when
someone tries updating!
Apollo Server 2.x has attempted to maintain full compatibility with versions
of Node.js which are still under Long Term Support agreements with the
Node.js Foundation. While this continues to mostly be true, file uploads
are an exception which we've now had to make.
Third-party open-source projects must absolutely do what's best for their
project. From an architecture standpoint, I suspect that we (the designers
behind Apollo Server) are mostly to blame for this. Namely, it's unfortunate
that we had made such an incredibly coupled integration with a third-party
package that we restricted our users from incrementally adopting the
changes (and new/improved functionality) of, in this particular case,
the `graphql-upload` package. I hope we can take better care with decisions
like this in the future!
Lastly, this commit also adds documentation to help those affected.
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.
* Example code snippet does not work
for the context it needs to return a connection.context and not a {}.
* Include not about what connection contains
* Add client awareness reference api and some docs
* Reword and add default behavior to docs
* update clientReferenceId docs to be more explicit
* Update the generateClientInfo to use headers
These are docs to accompany the `apollo-server-testing` utils
<!--
Thanks for filing a pull request on GraphQL Server!
Please look at the following checklist to ensure that your PR
can be accepted quickly:
-->
TODO:
* [ ] Update CHANGELOG.md with your change (include reference to issue & this PR)
* [ ] Make sure all of the significant new logic is covered by tests
* [ ] Rebase your changes on master so that they can be merged easily
* [ ] Make sure all tests and linter rules pass
<!--**Pull Request Labels**
While not necessary, you can help organize our pull requests by labeling this issue when you open it. To add a label automatically, simply [x] mark the appropriate box below:
- [ ] feature
- [ ] blocking
- [x] docs
To add a label not listed above, simply place `/label another-label-name` on a line by itself.
-->
This PR fixes#1836.
This PR enables developers to inject the http agent to be used on the network requests to apollo engine endpoint.
<!--
Thanks for filing a pull request on GraphQL Server!
Please look at the following checklist to ensure that your PR
can be accepted quickly:
-->
TODO:
* [x] Update CHANGELOG.md with your change (include reference to issue & this PR)
* [x] Make sure all of the significant new logic is covered by tests
* [x] Rebase your changes on master so that they can be merged easily
* [x] Make sure all tests and linter rules pass
<!--**Pull Request Labels**
While not necessary, you can help organize our pull requests by labeling this issue when you open it. To add a label automatically, simply [x] mark the appropriate box below:
- [ ] feature
- [ ] blocking
- [ ] docs
To add a label not listed above, simply place `/label another-label-name` on a line by itself.
-->
Fix grammar, and hopefully make the explanation a bit clearer.
It could also be said like this (for a smaller diff) ;-)
"By allowing the consumer of the API to see the full possibilities that an API can *deliver*, developers can"...
* Fix the example for "Using an Existing Schema"
The file caused the following error:
```
const gql = String.raw;
^
SyntaxError: Identifier 'gql' has already been declared
```
* Update migration-two-dot.md
* Update migration-two-dot.md
