mirror of
https://github.com/vale981/apollo-server
synced 2025-03-12 14:06:40 -04:00
38bf09b316
* 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.
29 lines
1.5 KiB
Markdown
29 lines
1.5 KiB
Markdown
# `apollo-engine-reporting-protobuf`
|
|
|
|
> **Note:** The Apollo Engine reporting API is subject to change. We strongly
|
|
> encourage developers to contact Apollo Engine support to discuss their use
|
|
> case prior to building their own reporting agent using this module.
|
|
|
|
This module provides JavaScript/TypeScript
|
|
[Protocol buffer](https://developers.google.com/protocol-buffers/) definitions
|
|
for the Apollo Engine reporting API. These definitions are generated for
|
|
consumption from the `reports.proto` file which is defined internally within
|
|
Apollo.
|
|
|
|
## Development
|
|
|
|
> **Note:** Due to a dependency on Unix tools (e.g. `bash`, `grep`, etc.), the
|
|
> development of this module requires a Unix system. There is no reason why
|
|
> this can't be avoided, the time just hasn't been taken to make those changes.
|
|
> We'd happily accept a PR which makes the appropriate changes!
|
|
|
|
Currently, this package generates a majority of its code with
|
|
[`protobufjs`](https://www.npmjs.com/package/protobufjs) based on the
|
|
`reports.proto` file. The output is generated with the `prepare` npm script.
|
|
|
|
The root of the repository provides the `devDependencies` necessary to build
|
|
these definitions (e.g. `pbjs`, `pbts`, `protobuf`, etc.) and the the `prepare`
|
|
npm script is invoked programmatically via the monorepo tooling (e.g. Lerna)
|
|
thanks to _this_ module's `postinstall` script. Therefore, when making
|
|
changes to this module, `npx lerna run prepare` should be run from the **root**
|
|
of this monorepo in order to update the definitions in _this_ module.
|