8496387c78
* Initial commit * 0.0.3 * Replace endOffset with duration in resolver calls * 0.0.4 * Fix duration * 0.0.5 * Remove unnecessary schema level resolve function and return schema * Update README * 0.0.6 * Update README * Update dependencies * 0.0.7 * Update README * set package.json to point to this repository (#3) * Update dependencies Fixes #4. * 0.0.8 * Add asynciterable support to tsconfig.json * Skip trace collection when context or context._traceCollector is undefined Fixes #5. * 0.0.9 * Rewrite to use graphql-extensions * 0.0.10 * 0.0.11 * 0.1.0 * Update graphql-extensions dependency and downgrade TS target * 0.1.1 * Update README * Update README * Increase version range for `graphql` peerDependency. (#7) * 0.1.2 * Update dependencies * 0.1.3 * [apollo-bot] Update the Issue/PR Templates with auto label (#9) * Update `graphql` peer dependency range to allow 0.13.x. * dev: Update TypeScript to latest version, v2.7.2. * dev: Update jest & dependencies to latest versions. * dev: Update type definitions for `graphql`, `node` and `jest`. * Allow `undefined` to return from `format`. (#12) * Allow `undefined` to return from `format`. TypeScript 2.7 introduced new "Strict Class Instantiation" rules which, as the name suggests, require properties which are intended to be set (eventually, to a type) be set during construction. Before this change, the `TracingExtension` class was deferred setting these private properties (namely, `startWallTime`, `endWallTime`, `startHrTime` and `duration`), but not during instantiation which required setting marking them as optional and guarding their usage in other methods which might use those (temporarily `undefined`, if even for a tick) properties. For example, the expectation that `format` is _only_ called after `requestDidStart` is not guaranteed with this configuration, even if it is expected under normal operation. Therefore, this change adds the additional guarding and updates the `format` method to return `undefined` in the event that it doesn't have the appropriate data. * Update `graphql-extensions` dependency to `~0.0.9`. Specifically, to take advantage of a type which landed in `graphql-extensions@0.0.9` thanks to https://github.com/apollographql/graphql-extensions/pull/10. * 0.1.4 * Update for graphql-extensions@0.1.0 API (#13) * Upgrade to TypeScript 2.8 * Add tslint and prettier * Update for graphql-extensions@0.1.0 API * 0.2.0-beta.0 * Make work with newest API usage format() now gets called before the requestDidStart() EndHandler. * 0.2.0-beta.1 * remove unused files from tracing package * upgrade packages, fix compilation bugs, and add test |
||
|---|---|---|
| .. | ||
| src | ||
| package-lock.json | ||
| package.json | ||
| README.md | ||
| tsconfig.json | ||
Apollo Tracing (for Node.js)
This package is used to collect and expose trace data in the Apollo Tracing format.
It relies on instrumenting a GraphQL schema to collect resolver timings, and exposes trace data for an individual request under extensions as part of the GraphQL response.
This data can be consumed by Apollo Engine or any other tool to provide visualization and history of field-by-field execution performance.
Usage
Apollo Server
Apollo Server includes built-in support for tracing from version 1.1.0 onwards.
The only code change required is to add tracing: true to the options passed to the Apollo Server middleware function for your framework of choice. For example, for Express:
app.use('/graphql', bodyParser.json(), graphqlExpress({
schema,
context: {},
tracing: true,
}));
If you are using
express-graphql, we recommend you switch to Apollo Server. Bothexpress-graphqland Apollo Server are based on thegraphql-jsreference implementation, and switching should only require changing a few lines of code.