Currently, the only place that we use `lodash` in the entire `apollo-server`
repository is to utilize the `sortBy` function in this signature generation.
Looking at the bundle stats, it appears that lodash represents 7.1% of the
`apollo-server` package. We're a server, so bundle size is generally less
of a concern, but it's still not to be ignored, particularly as we move into
worker environments. More pressingly though, since this package will be
utilized by the `apollo` CLI, we'll be shaving precious download time off
the invocation of `npx apollo` if we can get this down.
By switching to the modular package (but still depending on `@types/lodash`
for _just_ the `ListIteratee` type — which we only need in development — we
should be able to trim 55.4kB minified (19.1kB minified+gzip'd) off the
`apollo-server` build.
cc @trevor-scheer @jbaxleyiii @martijnwalraven
These AST visitors and transformations are more generally usable for other
purposes rather than just the Apollo Engine signature reporting and would
seem to belong in a module of their own.
Many of these signature calculation functions are now utilized in tools or
helpers which are not directly related to `apollo-server` functionality,
including various aspects of the `apollo` CLI which live within
`apollo-tooling`.
Currently, because of `apollo`'s dependency on `apollo-engine-reporting` for
this signature, this requires bringing in the entire dependency tree which
`apollo-server-core` relies on since `apollo-engine-reporting` depends on
`apollo-server-core`.
By moving this into this new `apollo-graphql` utility library, we're able to
trim that rather hefty dependency tree and drastically reduce the download
for running, say, `npx apollo`.
* 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
I get the following error when using the apollo-server-core with typescript (3.2.4) :
node_modules/apollo-server-core/dist/types.d.ts:4:8 - error TS1192: Module '"/node_modules/@types/ws/index"' has no default export.
import WebSocket from 'ws';
The change fixes this error!
This is consistent with the old engineproxy interpretation of cache hints. We
special-case scalar fields to inherit their parent field's hints for
simplicity (so you don't have to hint every scalar field in a hinted object),
but when the parent field is non-root that inherited hint gets defaultMaxAge
applied to it. When the parent field is the root, that inherited hint doesn't
get defaultMaxAge applied because we don't run willResolveField for the root
query.
Includes a CHANGELOG update for #2197.
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
This PR contains the following updates:
| Package | Type | Update | Change | References |
|---|---|---|---|---|
| @​types/fast-json-stable-stringify | devDependencies | pin | `^2.0.0` -> `2.0.0` | [source](https://togithub.com/DefinitelyTyped/DefinitelyTyped) |
📌 **Important**: Renovate will wait until you have merged this Pin PR before creating any *upgrade* PRs for the affected packages. Add the preset `:preserveSemverRanges` your config if you instead don't wish to pin dependencies.
---
### Renovate configuration
📅 **Schedule**: "after 6pm every weekday,before 5am every weekday" in timezone America/Los_Angeles.
🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied.
♻️ **Rebasing**: Whenever PR is stale, or if you modify the PR title to begin with "`rebase!`".
👻 **Immortal**: This PR will be recreated if closed unmerged. Get [config help](https://togithub.com/renovatebot/config-help/issues) if that's undesired.
---
- [ ] <!-- renovate-rebase -->If you want to rebase/retry this PR, check this box
---
This PR has been generated by [Renovate Bot](https://togithub.com/marketplace/renovate). View repository job log [here](https://renovatebot.com/dashboard#apollographql/apollo-server).
