This was inadvertently left in place as I didn't run into the usual
merge-conflict that I usually do on the CHANGELOG.md which is my natural
ergonomic which usually leads me to fixing it. Apologies!
This TEMPORARILY reverts commit 069110b353,
which was the result of the work done in #1971 by @rkorrelboom.
Unfortunately, we need to put this on ice while we wait for movement on a
package naming conflict. The dialog surrounding this is under way, as
I've explained in the PR:
https://github.com/apollographql/apollo-server/pull/1971#issuecomment-456817749
I'm excited to re-land this in an upcoming version, but there's no reason to
block the 2.4.0 release for it right now.
I will open a new PR with the work from #1971 in due time.
* Remove `willStart` from `apollo-server`, already called via `...-express`.
When the request pipeline was initially introduced, the integrations
had yet to be updated to call the new life-cycle events. Now, the
integrations have all caught up, but `apollo-server` is still calling
`willStart`, despite the fact that its dependency which provides the actual
server implementation — `apollo-server-express` – is _also_ calling it,
resulting in double invocation of this event.
I suspect some follow-up work should guard against this possibility, but for
now this should remove the duplication.
* Update CHANGELOG.md for #2239.
Ref: https://github.com/apollographql/apollo-server/pull/2239
Since we already write to the persisted query cache asynchronously (and
intentionally do not await the Promise) this won't have any affect on the
current behavior of when the persisted query cache is written to in the
event of an executable request, but if an operation comes in and doesn't
parse or validate, we'll avoid wasting cache space on an operation that will
never execute.
Additionally, in a similar light, if a plugin throws an error which stops
execution, we can avoid the side-effect of writing to the persisted query
cache.
In terms of the APQ behavior, while this could cause additional round-trips
for a client which repeatedly sends an invalid operation, that operation is
never going to successfully finish anyway. While developer tooling will
help avoid this problem in the first place, this refusal to store an invalid
operation in the APQ cache could actually help diagnose a failure since the
full operation (rather than just the SHA256 of that document) will appear
in the browser's dev-tools on the retry.
If we're looking to spare parsing and validating documents which we know are
going to fail, I think that's going to be a better use of the (new)
`documentStore` cache (#2111), since its in-memory and can accommodate a
more complex data structure which includes the validation errors from the
previous attempt which will, of course, be the same when validating the same
operation against the same schema again. As the PR that introduced that
feature shows, sparing those additional parses and validations (cached APQ
documents still needs to be parsed and validated, currently) will provide a
more successful performance win overall.
Ref: https://github.com/apollographql/apollo-server/pull/2111
* feat(fastify) Apollo Fastify server integration resolve#626
* feat(fastify) Use createHandler instead of applyMiddleware #626
* feat(fastify) Fix integration test for node 10 #626
* feat(fastify) Update README's with fastify createHandler interface #626
* feat(fastify) Implement the fastify createHandler as a synchronous method #626
* (fastify) Tweaks to re-align with the parallel work in #2054.
* (fastify): Use port 9999 rather than 8888 for tests. Because Gatsby.
This specific port per integration is pretty brittle to begin with, but it
does work. Currently, the fact that it works is facilitated by the fact
that most people don't use 5555 (Hapi) and 6666 (Express) for anything.
That said, the ever-popular Gatsby uses 8888 by default, so let's use 9999!
* (fastify) Remove duplicative assertion in upload initialization.
* (fastify) Implement fastify upload middleware
* (fastify) Fix linting issues
* (fastify) Update package-lock
* refactor: switch `json-stable-stringify` to `fast-json-stable-stringify`
* chore: drop `@types/json-stable-stringify`
* Update CHANGELOG.md for #2065.
* AER: Remove encodedTraces to prevent duplicates
When there are multiple instances of apollo-engine-reporting, the
`Trace.encode` method gets wrapped each time to add the
`encodedTraces`. In order to prevent them from being added to the
protobuf multiple times, we remove the encodedTraces after adding them
once
* Add changelog
* Move incremental Trace encoding to a-e-r-protobuf
To enable incrmental compilation of traces, we add a patch to the
Trace.encode method generated by protobujs to accept and store encoded
traces. Occassionally with multiple instances of apollo-engine-reporting
that share the same version of the protobuf, the wrapper method gets
applied more than once. In order to ensure that the wrapper only gets
applied once, we patch the Trace.encode method inside of
apollo-engine-protobuf.
tsc hangs on the processing the generated protobuf.js files, so the
tsconfig.json ignores the generated protobuf file. In order for the
typescript index.ts file to compile the generated protobuf.js file is
output to the src folder. To ensure the protobuf files are available to
the production build, `npm run compile` copies the protobuf file
manually from src to dist.
* Reexport protobuf import after modification
`export * from './protobuf'` exports the unmodified reference
* Update comment on Trace.encode to point at a-e-r-p
The override now occurs inside of apollo-engine-reporting-protobuf due
to the case of having multiple reporting challenges, so we need to
update the comments to help indicate that
* Remove typescript build step
In order to simplify the generation of this library, we move the change
the index.ts file into index.js and remove the typescript build step.
Since the type safety is created by the protobufjs generation, this
seems acceptable. In general this portion of the code should remain
relatively stable, so generating and copying the code with `prepare`
remains reasonable.
BUGFIX: the playground page is currently being served without a content type
<!--
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)
* [ ] 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
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.
Follow-up on the update to `graphql-playground-html` in previous release by
also bumping the minor version of the `graphql-playground-react` dependency
to `1.7.10` — which is the version requested from the from the CDN bundle by
`graphql-playground-html`.
Ref: https://github.com/apollographql/apollo-server/pull/2037
With any luck, we will no longer necessitate our fork which removed the
`graphql-config` dependency thanks to the work done in:
https://github.com/prisma/graphql-playground/pull/874🎉
Most notably though, this fixes a documentation scrolling problem with
Safari.
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.
-->
Since we’ve moved to independent versioning the statement about every package within this repository being at the same version is no longer true. While we’ll need to improve our `CHANGELOG.md` story a bit to account for this, it’s best that we remove this statement to avoid confusing library consumers.
