Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide ability to specify client info in traces #1631

Merged
merged 5 commits into from
Sep 18, 2018
Merged

Conversation

evans
Copy link
Contributor

@evans evans commented Sep 7, 2018

Adds the createClientInfo to apollo-engine-reporting, which enables the
differentiation of clients based on the request, operation, and
variables. This could be extended to include the response. However for
the first release. It doesn't quite make sense.

TODO:

  • Update CHANGELOG.md with your change (include reference to issue & this PR)
  • Make sure all of the significant new logic is covered by tests
  • Rebase your changes on master so that they can be merged easily
  • Make sure all tests and linter rules pass

@ghost ghost added the ⛲️ feature New addition or enhancement to existing solutions label Sep 7, 2018
@ghost ghost added the ⛲️ feature New addition or enhancement to existing solutions label Sep 7, 2018
@@ -348,3 +348,9 @@ addMockFunctionsToSchema({
* `maskErrorDetails`: boolean

Set to true to remove error details from the traces sent to Apollo's servers. Defaults to false.

* createClientInfo?: (o: { request: Request, queryString?: string, parsedQuery?: DocumentNode, variables: Record<string, any>}) => ClientInfo;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we have a default createClientInfo function that looks to a known header or set of headers for these fields? Also, I think the naming could be better, since this is actually a function that takes in request details and generates the client information. Maybe clientInfoGenerator?

createClientInfo?: (
o: {
request: Request;
queryString?: string;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm confused as to why we're passing the query information here? I can understand using the variables as well as query extensions, but I don't understand the query string.

@@ -34,6 +34,12 @@ Traces.encode = function(message, originalWriter) {
return writer;
};

export interface ClientInfo {
clientName?: string;
clientAddress?: string;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we can leave out clientAddress and clientVersion for now

Adds the createClientInfo to apollo-engine-reporting, which enables the
differentiation of clients based on the request, operation, and
variables. This could be extended to include the response. However for
the first release. It doesn't quite make sense.
The frontend will not support it in the near future
createClientInfo -> generateClientInfo
Copy link
Contributor

@zionts zionts left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good! Just some small comment nitpicks and an ask about type coercion and default values.

Apollo backend. The context field is the execution context passed to the
resolvers and the extensions field is the field provided in the request's
query, operationName, and variables. `ClientInfo` contains fields for
`clientName` and `clientVersion`, which can both be optional. The default
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can both be null?

@@ -51,6 +57,10 @@ export class EngineReportingExtension<TContext = any>
const root = new Trace.Node();
this.trace.root = root;
this.nodes.set(responsePathAsString(undefined), root);
this.generateClientInfo =
options.generateClientInfo ||
// Default to using the clientInfo field of the request
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

clientInfo extensions field

resolvers and the extensions field is the field provided in the request's
query, operationName, and variables. `ClientInfo` contains fields for
`clientName` and `clientVersion`, which can both be optional. The default
value copies the respective fields from the `extensions`'s `clientInfo`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it clear enough to just say "the extensions's field" here, especially since query extensions are not standard? Maybe we should say the POST body's extensions.clientInfo field?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like POST body's extensions.clientInfo! Reading the sentence again, it isn't quite clear 🎉

this.generateClientInfo =
options.generateClientInfo ||
// Default to using the clientInfo field of the request
(({ extensions }) => (extensions && extensions.clientInfo) || {});
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What happens if clientInfo type doesn't match the object expected?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

clientName and clientVersion will be undefined

context: o.context,
extensions: o.extensions,
});
this.trace.clientName = clientName || '';
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we do empty string for unrecognized clients or have a designated enum, like "UNKNOWN"? Either way, we should think about what happens with clients that specify their client information as the default we use for unknown clients -- is that OK?

@evans evans merged commit 96af44e into master Sep 18, 2018
@evans evans deleted the evans/client-id branch September 18, 2018 05:45
abernix added a commit that referenced this pull request Sep 20, 2018
The `generateClientInfo` API, used to set client identification attributes
within traces, is an experimental API and is subject to removal or change in
a future (major) Apollo Server release.

Ref: #1631
abernix added a commit that referenced this pull request Sep 27, 2018
abernix pushed a commit that referenced this pull request Sep 27, 2018
* Provide ability to specify client info in traces

Adds the createClientInfo to apollo-engine-reporting, which enables the
differentiation of clients based on the request, operation, and
variables. This could be extended to include the response. However for
the first release. It doesn't quite make sense.

* Use extensions and context in createClientInfo

* Remove support for clientAddress

The frontend will not support it in the near future

* create -> generate and make default generator

createClientInfo -> generateClientInfo

* Clarify default values
abernix added a commit that referenced this pull request Sep 27, 2018
The `generateClientInfo` API, used to set client identification attributes
within traces, is an experimental API and is subject to removal or change in
a future (major) Apollo Server release.

Ref: #1631
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Apr 22, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
⛲️ feature New addition or enhancement to existing solutions
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants