-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
feat(tracing): GraphQL and Apollo Integrations #3953
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
Conversation
size-limit report
|
Hi @onurtemizkan I worked with these developers on these blog articles, this one used a Resolver in his approach too and this used didEncounterErrors for error monitoring |
Hi @thinkocapo, yeah I guess that's the sensible way to trace GraphQL transactions. Just if we could track GraphQL resolvers without relying on Apollo (as resolver is a core GraphQL concept), our plugin would be available for a wider range of projects. But still, this works, and most projects are using Apollo anyways, so we should be fine for now. |
This pull request has gone three weeks without activity. In another week, I will close it. But! If you comment or otherwise update it, I will reset the clock, and if you label it "A weed is but an unloved flower." ― Ella Wheeler Wilcox 🥀 |
The approach in the first blog post doesn't work properly when batching is involved, or when a request contains multiple queries. Here's a more detailed report of what I mean: https://forum.sentry.io/t/transactions-with-graphql/13702 To clarify, it completely breaks down with https://www.apollographql.com/docs/react/api/link/apollo-link-batch-http/ I'm hoping the approach in this PR works better in this regard. Is there anything missing here? |
Hi @onurtemizkan! Could you please help me summarize the current status for this PR? Are we settled on the current approach? Thanks! |
Hi @rhcarvalho. At this stage, it would be wonderful to get some reviews about the approach taken. The summary of this approach:
I'll be happy to put more work on this PR to refine/test more, after getting reviews, but this implementation has the basic functionality and is working in the current state. |
69c89f9
to
94074fc
Compare
size-limit report 📦
|
311dc78
to
c634e2c
Compare
apollo() { | ||
const integration = dynamicRequire(module, './integrations/apollo') as { | ||
Apollo: IntegrationClass<Integration>; | ||
}; | ||
return new integration.Apollo(); | ||
}, | ||
graphql() { | ||
const integration = dynamicRequire(module, './integrations/graphql') as { | ||
GraphQL: IntegrationClass<Integration>; | ||
}; | ||
return new integration.GraphQL(); | ||
}, |
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.
tbh I'd rather make these opt-in rather than auto-enabled.
Any possible way we can integration test this? We can do it in the PR moving forward as well.
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.
@AbhiPrasad, updated and added the tests. 👍 Docs are coming up.
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.
Can we make sure these are not auto-enabled?
We'll also need docs for this! |
beed667
to
4dcc09e
Compare
@@ -0,0 +1,33 @@ | |||
import { assertSentryTransaction, getEnvelopeRequest, runServer, conditionalTest } from '../../../utils'; | |||
|
|||
conditionalTest({ min: 12 })(() => { |
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.
not supported by node 10?
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.
Looks like they dropped support for Node 10.
https://github.com/graphql/graphql-js/blob/main/package.json#L30
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.
Cool, can we leave a comment above the test linking to the package.json?
0040b0f
to
299aeb3
Compare
87b80a9
to
44e8e46
Compare
44e8e46
to
f520528
Compare
f520528
to
117a868
Compare
Thanks for this @onurtemizkan! Let's not forget to merge getsentry/sentry-docs#5089 when this is released. |
Summary:
This PR introduces basic tracing functionality for server-side GraphQL query resolutions.
My original intent was to implement a single generic integration for GraphQL but trying to patch resolvers inside graphql-js ended up being very painful (if not impossible) as most of the resolver-level execution logic is strictly unexposed and there seem to be no instances that store resolvers we can monkey-patch.
So I ended up implementing two integrations for both GraphQL and Apollo.
GraphQL integration has very basic functionality and simply works as the parent node for all resolvers in the execution tree when used with Apollo. Without Apollo, it's just a simple span for the whole GQL execution process. But may still be useful.
Apollo integration works on the resolver level, supports nested resolutions, and treats DB operations as children.
I think there is a lot of room for improvement for both integrations. But wanted to get opinions and reviews before investing more time in them.
Resolves: #3774