✨ [RUM-11434] GraphQL support #3805
Conversation
|
✅ Tests 🎉 All green!❄️ No new flaky tests detected 🎯 Code Coverage 🔗 Commit SHA: 0e6b39f | Docs | Was this helpful? Give us feedback! |
Bundles Sizes Evolution
🚀 CPU Performance
🧠 Memory Performance
|
|
/to-staging |
|
View all feedbacks in Devflow UI.
Commit 079d9195f2 will soon be integrated into staging-36.
We couldn't automatically merge the commit 079d9195f2 into staging-36! To solve the conflicts directly in Github, click here to create a fix pull request. Alternatively, you can also click here reset the integration branch or use the following Slack command: |
|
/to-staging |
|
View all feedbacks in Devflow UI.
Commit f396a31845 will soon be integrated into staging-36.
Commit f396a31845 has been merged into staging-36 in merge commit 2b96c832fb. Check out the triggered pipeline on Gitlab 🦊 If you need to revert this integration, you can use the following command: |
Integrated commit sha: f396a31 Co-authored-by: rgaignault <[email protected]>
| return {} | ||
| } | ||
|
|
||
| const graphqlMetadata = extractGraphQlMetadata(request.init?.body, graphQlConfig.trackPayload) |
There was a problem hiding this comment.
❓ question: does anything prevent customers to use Request for their calls? cf input field of RequestCompleteEvent
There was a problem hiding this comment.
Hmm I guess no but it's a readable stream so we can not access it at this time, what are you thoughts about handling this case ?
There was a problem hiding this comment.
From my understanding, you can use Request with a string body, so I'd support this usage like we already do in fetchObservable.
|
/to-staging |
|
View all feedbacks in Devflow UI.
Commit f396a31845 will soon be integrated into staging-37.
Commit f396a31845 has been merged into staging-37 in merge commit 635a7b715d. Check out the triggered pipeline on Gitlab 🦊 If you need to revert this integration, you can use the following command: |
Integrated commit sha: f396a31 Co-authored-by: rgaignault <[email protected]>
| operationType: 'query' | 'mutation' | 'subscription' | ||
| operationName?: string | ||
| variables?: string | ||
| payload?: string | ||
| } |
There was a problem hiding this comment.
Hey, i'm just a GraphQL fan checking in. Feel free to disregard.
Just curious: do we also plan to supporting persisted queries or anything in the extensions field? Persisted queries aren't officially in the GraphQL spec but supported by Apollo and Relay. When the persisted query id/hash is provided, the query document itself won't be provided. This would allow customers to figure out what was executed by the client. It might be worth looking into saving the entire extensions field. There shouldn't be anything privacy sensitive in there if they're following the spec and only use it for "implementation-specific additional information."
Apollo seems to include it in the extensions field:
{
operationName: 'MyQuery',
variables: null,
extensions: {
persistedQuery: {
version: 1,
sha256Hash: hashOfQuery
}
}
}
Motivation
GraphQL calls in RUM currently appear as generic POST /graphql entries, making it hard to distinguish or debug specific operations. Mobile SDKs already support GraphQL OOTB tracking, but the Browser SDK lacked equivalent functionality. This PR introduces native GraphQL request enrichment so operations can be meaningfully identified in RUM without relying on beforeSend customization.
Changes
New configuration option :
Detects matching GraphQL requests and enriches resource events with:
operationType, operationName ,variables, payload (query body, optional via trackPayload, truncated to 32KB)
Test instructions
Checklist