* Add AS constructor with context usage to tests
* fix(typing): Context template type should be 'object' and not 'any'
```context?: ContextFunction<ExpressContext, any> | Context<any>;```
is
```context?: ContextFunction<ExpressContext, any> | any;```
which is
```context?: any;```
https://github.com/Microsoft/TypeScript/issues/18568
Since the ContextFunction<...> part is ignored, no type hinting will be provided when a function is passed to `context`. We don't really mean `any`, we mean an object with any shape, so we should use `object` instead
* fix(typing): type ContextFunction params separately from resulting context object
* Update changelog
* rename: ContextContent -> ProducedContext
* Type formatErrors function to specify that it accepts and returns ApolloError
* Update changelog
* type(formatErrors): accept GraphQLError, return GraphQLFormattedError
* update changelog
* typing: context function could return value synchronously
* Create ApolloServerExpressConfig type that has req and res in context
* Have apollo-server-express's constructor also use the express-specific config
* Update changelog
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.
