Release 2.24.0 #5136
Merged
Release 2.24.0 #5136
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The usage reporting plugin in `apollo-server-core` is not the first tool Apollo
built to report usage to Studio. Previous iterations such as `optics-agent` and
`engineproxy` reported a combination of detailed per-field single-operation
performance *traces* and summarized *stats* of operations to Apollo's
servers. When we built this TypeScript usage reporting plugin in 2018, for the
sakes of expediency we did something different: it only sent traces to Apollo's
servers. This meant that the performance of every single single user operation
was described in detail to Apollo's servers. Studio is not an exhaustive trace
warehouse: we have always *sampled* the traces received, making only some of
them available via Studio's Traces UI. The other traces were converted to stats
inside Studio's servers.
While this meant that the reporting agent was simpler than the previous
implementations (no need to be able to describe performance statistics), it also
meant that the protocol used to talk to Studio consumed a lot more bandwidth (as
well as CPU time for encoding traces).
This PR returns us to the world where Studio usage is reported as a combination
of stats and traces. It takes a slightly different approach than the previous
implementations: instead of reporting stats and traces in parallel, usage
reports contain both stats and traces. Each GraphQL operation is described
either as a trace or as stats, not both.
We expect this to significantly reduce the network and CPU requirements of
sending usage reports to Studio. It should not significantly affect the
experience of using Studio: we have always heavily sampled traces in Studio
before saving them to the trace warehouse, and the default heuristic for which
operations to send as traces works similarly to the heuristic used in Studio's
servers.
This PR introduces an option `experimental_sendOperationAsTrace` to allow you to
control whether a given operation is sent as trace or stats. This is truly an
experimental option that may change at any time. For example, you should not
rely on the fact that this will be called on all operations after the operation
is done with a full, or on its signature, or even that it exists. It is likely
that future improvements to the usage reporting plugin will change how
operations are observed so that we don't have to collect a full trace before
deciding how to represent the operation.
Some other notes:
- Upgrade our fork `@apollo/protobufjs` with a few improvements:
- New `js_use_toArray` option which lets you encode repeated fields from
objects that aren't stored in memory as arrays but expose `toArray`
methods. We use this so that we can build up `DurationHistogram`s and
map-like objects in a non-array fashion and only convert to array at
encoding time.
- New `js_preEncoded` option which allows you to encode messages in repeated
fields as buffers (Uint8Arrays). This helps amortize encoding cost of a
large message over time instead of freezing the event loop to encode the
whole message at once. This replaces an old hack we used for one field with
something built in to the protobuf compiler (including correct TypeScript
typings).
- New `--no-from-object` flag which we use to reduce the size of generated
code (as we don't use the fromObject protobuf.js API).
- In order to help us validate that the trace->stats code in this PR matches
similar code in Studio's servers, the flag
`internal_includeTracesContributingToStats` sends the traces that contribute
to stats in a special field. This is something we only use as part of our own
validation in our servers; for your graphs it will have no effect other than
increasing message size.
- Viewing traces in Studio is only available on paid plans. The usage-reporting
endpoint now tells the plugin whether traces are supported on your graph's
plan; if not supported, the plugin will switch to sending all operations as
stats (regardless of the value of `experimental_sendOperationAsTrace`) after
the first report.
- We try to estimate the message size compared to maxUncompressedReportSize via
a rough estimate about how big the leaf nodes of the stats messages will be
rather than carefully counting how much space is used by each number and
histogram. We do take the lengths of all strings into account.
- By mistake, this plugin never sent the cache policy on traces, meaning that
visualizing cache-specific stats in Studio did not work. This is now fixed.
This project was begun by @jsegaran and completed by @glasser.
- apollo-cache-control@0.13.0-alpha.0 - apollo-datasource-rest@0.13.0-alpha.0 - apollo-datasource@0.9.0-alpha.0 - apollo-reporting-protobuf@0.7.0-alpha.0 - apollo-server-azure-functions@2.24.0-alpha.0 - apollo-server-cache-memcached@0.8.0-alpha.0 - apollo-server-cache-redis@1.5.0-alpha.0 - apollo-server-caching@0.7.0-alpha.0 - apollo-server-cloud-functions@2.24.0-alpha.0 - apollo-server-cloudflare@2.24.0-alpha.0 - apollo-server-core@2.24.0-alpha.0 - apollo-server-env@3.1.0-alpha.0 - apollo-server-express@2.24.0-alpha.0 - apollo-server-fastify@2.24.0-alpha.0 - apollo-server-hapi@2.24.0-alpha.0 - apollo-server-integration-testsuite@2.24.0-alpha.0 - apollo-server-koa@2.24.0-alpha.0 - apollo-server-lambda@2.24.0-alpha.0 - apollo-server-micro@2.24.0-alpha.0 - apollo-server-plugin-base@0.12.0-alpha.0 - apollo-server-plugin-operation-registry@0.10.0-alpha.0 - apollo-server-plugin-response-cache@0.8.0-alpha.0 - apollo-server-testing@2.24.0-alpha.0 - apollo-server-types@0.8.0-alpha.0 - apollo-server@2.24.0-alpha.0 - apollo-tracing@0.14.0-alpha.0 - graphql-extensions@0.14.0-alpha.0
|
The main change in this release is #4142, which should decrease the size of reports sent by Studio usage reporting without a changing the Studio user experience. |
|
We have a prerelease out at 2.24.0-alpha.0. As usual, you will want to make sure you're depending on this version of |
See apollographql/protobuf.js#7 A future version could fully remove Long support from our fork but we aren't quite there yet.
- apollo-cache-control@0.13.0-alpha.1 - apollo-datasource-rest@0.13.0-alpha.1 - apollo-reporting-protobuf@0.7.0-alpha.1 - apollo-server-azure-functions@2.24.0-alpha.1 - apollo-server-cloud-functions@2.24.0-alpha.1 - apollo-server-cloudflare@2.24.0-alpha.1 - apollo-server-core@2.24.0-alpha.1 - apollo-server-express@2.24.0-alpha.1 - apollo-server-fastify@2.24.0-alpha.1 - apollo-server-hapi@2.24.0-alpha.1 - apollo-server-integration-testsuite@2.24.0-alpha.1 - apollo-server-koa@2.24.0-alpha.1 - apollo-server-lambda@2.24.0-alpha.1 - apollo-server-micro@2.24.0-alpha.1 - apollo-server-plugin-base@0.12.0-alpha.1 - apollo-server-plugin-operation-registry@0.10.0-alpha.1 - apollo-server-plugin-response-cache@0.8.0-alpha.1 - apollo-server-testing@2.24.0-alpha.1 - apollo-server-types@0.8.0-alpha.1 - apollo-server@2.24.0-alpha.1 - apollo-tracing@0.14.0-alpha.1 - graphql-extensions@0.14.0-alpha.1
|
Published |
* chore(deps): update dependency node-fetch to v2.6.1 * tests: Use `toString()` method to test Buffer contents As of `node-fetch@2.4.0`, its internal representation of `body` is now normalized to a `Buffer` during `Request` construction, and will always be returned as a `Buffer`, rather than having the `body` being either a String _or_ a Buffer. This defeated the way we were testing the `body` but shouldn't affect the actual `Response`'s `body`. Ref: node-fetch/node-fetch@7d3293200a91a Co-authored-by: Renovate Bot <bot@renovateapp.com> Co-authored-by: Jesse Rosenberger <git@jro.cc>
…5144) Co-authored-by: Renovate Bot <bot@renovateapp.com>
- apollo-cache-control@0.13.0-alpha.2 - apollo-datasource-rest@0.13.0-alpha.2 - apollo-reporting-protobuf@0.7.0-alpha.2 - apollo-server-azure-functions@2.24.0-alpha.2 - apollo-server-cloud-functions@2.24.0-alpha.2 - apollo-server-cloudflare@2.24.0-alpha.2 - apollo-server-core@2.24.0-alpha.2 - apollo-server-express@2.24.0-alpha.2 - apollo-server-fastify@2.24.0-alpha.2 - apollo-server-hapi@2.24.0-alpha.2 - apollo-server-integration-testsuite@2.24.0-alpha.2 - apollo-server-koa@2.24.0-alpha.2 - apollo-server-lambda@2.24.0-alpha.2 - apollo-server-micro@2.24.0-alpha.2 - apollo-server-plugin-base@0.12.0-alpha.2 - apollo-server-plugin-operation-registry@0.10.0-alpha.2 - apollo-server-plugin-response-cache@0.8.0-alpha.2 - apollo-server-testing@2.24.0-alpha.2 - apollo-server-types@0.8.0-alpha.2 - apollo-server@2.24.0-alpha.2 - apollo-tracing@0.14.0-alpha.2 - graphql-extensions@0.14.0-alpha.2
- apollo-cache-control@0.13.0 - apollo-datasource-rest@0.13.0 - apollo-datasource@0.9.0 - apollo-reporting-protobuf@0.7.0 - apollo-server-azure-functions@2.24.0 - apollo-server-cache-memcached@0.8.0 - apollo-server-cache-redis@1.5.0 - apollo-server-caching@0.7.0 - apollo-server-cloud-functions@2.24.0 - apollo-server-cloudflare@2.24.0 - apollo-server-core@2.24.0 - apollo-server-env@3.1.0 - apollo-server-express@2.24.0 - apollo-server-fastify@2.24.0 - apollo-server-hapi@2.24.0 - apollo-server-integration-testsuite@2.24.0 - apollo-server-koa@2.24.0 - apollo-server-lambda@2.24.0 - apollo-server-micro@2.24.0 - apollo-server-plugin-base@0.12.0 - apollo-server-plugin-operation-registry@0.10.0 - apollo-server-plugin-response-cache@0.8.0 - apollo-server-testing@2.24.0 - apollo-server-types@0.8.0 - apollo-server@2.24.0 - apollo-tracing@0.14.0 - graphql-extensions@0.14.0
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
As with release PRs in the past, this is a PR tracking a
release-x.y.zbranch for an upcoming release of Apollo Server. 🙌 The version in the title of this PR should correspond to the appropriate branch.Check the appropriate milestone (to the right) for more details on what we hope to get into this release!
The intention of these release branches is to gather changes which are intended to land in a specific version (again, indicated by the subject of this PR). Release branches allow additional clarity into what is being staged, provide a forum for comments from the community pertaining to the release's stability, and to facilitate the creation of pre-releases (e.g.
alpha,beta,rc) without affecting themainbranch.PRs for new features might be opened against or re-targeted to this branch by the project maintainers. The
mainbranch may be periodically merged into this branch up until the point in time that this branch is being prepared for release. Depending on the size of the release, this may be once it reaches RC (release candidate) stage with an-rc.xrelease suffix. Some less substantial releases may be short-lived and may never have pre-release versions.When this version is officially released onto the
latestnpm tag, this PR will be merged intomain.