-
Notifications
You must be signed in to change notification settings - Fork 257
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
@apollo/gateway - Expose the current request query path to the "willSendRequest" and "didReceiveResponse" hooks #2384
@apollo/gateway - Expose the current request query path to the "willSendRequest" and "didReceiveResponse" hooks #2384
Conversation
…zenkot/federation into current_request_graph_path_exposure
👷 Deploy request for apollo-federation-docs pending review.Visit the deploys page to approve it
|
🦋 Changeset detectedLatest commit: 2da416c The changes in this PR will be included in the next version bump. This PR includes changesets to release 7 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. |
…zenkot/federation into current_request_graph_path_exposure
Thanks again for opening a PR. We have filed this PR as under review, and will provide feedback shortly. |
@korinne hey! any news regarding this? maybe there's something I can do from my side to push it forward? |
gateway-js/src/datasources/types.ts
Outdated
/** | ||
* The path to the current processed node within the graph query | ||
*/ | ||
nodeGraphPath?: ResponsePath; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd move this inside the INCOMING_OPERATION
part (that path makes no sense for a HEALTH_CHECK
or LOADING_SCHEMA
kind of request) and maybe rename it to something like pathInIncomingRequest
(we call incomingRequestContext
the total operation received by the gateway, and the "path" is really the path within that gateway operation at which this particular subgraph "sub-query" fits in, and that's probably how I would describe that field btw; I also wouldn't use node
in the name as that's query plan specific naming and most users aren't meant to be familiar with that).
Could be nice to also document that the path may be undefined
if it is unavailable, but will be empty (rather than undefined
) for "top-level" fetches.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the clarifications! I've adopted your guidelines.
.changeset/flat-books-sin.md
Outdated
"@apollo/gateway": patch | ||
--- | ||
|
||
Current request graph path exposure |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be awesome to expand this entry a bit. I'd suggest something along the lines of:
Exposes, for each subgraph request, the path in the overall gateway operation at which that subgraph request gets inserted. This path is now available as the
pathInIncomingRequest
field in the arguments ofRemoteGraphQLDataSource.willSendRequest
andRemoteGraphQLDataSource.didReceiveResponse
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Amazing. thanks!
…and changeset note, move pathInIncomingRequest to live within incoming operations context
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few last remarks. Sorry, I may not have been super clear in my previous ones.
@@ -67,6 +68,11 @@ export class RemoteGraphQLDataSource< | |||
options: GraphQLDataSourceProcessOptions<TContext>, | |||
): Promise<GatewayGraphQLResponse> { | |||
const { request, context: originalContext } = options; | |||
const pathInIncomingRequest = | |||
options.kind === GraphQLDataSourceRequestKind.INCOMING_OPERATION |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we need that test (we can use options.pathInIncomingRequest
directly): it's going to be undefined
for non-INCOMING_OPERATION
, but that feels almost more appropriate, and that avoids having to deal with null
at all.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I changed the null
assignment to undefined
, however, I cannot use options.pathInIncomingRequest
directly because the pathInIncomingRequest
property is not guaranteed to exist in options
because of the usage of typescript's union operator:
therefore, I must verify options.kind
before using it, unless you can think of another approach?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, correct, this is my bad.
gateway-js/src/datasources/types.ts
Outdated
|
||
/** | ||
* The path in the overall gateway operation at which that subgraph request gets inserted. | ||
* Please note that this could be set to `undefined` when the path is not available, or set to `null` for top-level fetch operations. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't believe the "or set to null
for top-level fetch operations" part is quite right: it should say "or be an empty array for top-level fetch operations".
What I mean/understand by "top-level" fetch operations is just subgraph fetches that are not entity fetches but rather query some Query
/Mutation
fields, and those will still be GraphQLDataSourceRequestKind.INCOMING_OPERATION
but where the path
in executeQueryPlan
will be empty.
Your current patch sets null
for queries that are not GraphQLDataSourceRequestKind.INCOMING_OPERATION
, but those are queries that don't belong to the execution of a gateway query: they are instead "maintenance" queries the gateway does for either refreshing it's understanding of the schema or "health checks" of the subgraph. As said in my other comment, having the path to undefined
to mean "not available" is fine for those imo.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry. Misunderstood. Got you now.
No worries. Thanks a lot of your responsiveness and explanations. I've made a few adjustments according to your comments, and also explained why as far as I can tell I cannot use |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lgtm. Thanks a lot for the contribution.
@@ -67,6 +68,11 @@ export class RemoteGraphQLDataSource< | |||
options: GraphQLDataSourceProcessOptions<TContext>, | |||
): Promise<GatewayGraphQLResponse> { | |||
const { request, context: originalContext } = options; | |||
const pathInIncomingRequest = | |||
options.kind === GraphQLDataSourceRequestKind.INCOMING_OPERATION |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, correct, this is my bad.
Description:
Exposed the path to the node currently resolved by the gateway to the willSendRequest and didReceiveResponse hooks.
Solves #2353