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

Graphql requests are not monitoring friendly #7130

Closed
bcaudan opened this issue Oct 7, 2020 · 10 comments
Closed

Graphql requests are not monitoring friendly #7130

bcaudan opened this issue Oct 7, 2020 · 10 comments

Comments

@bcaudan
Copy link

bcaudan commented Oct 7, 2020

Intended outcome:

Be able to monitor graphql requests through a third party monitoring library.

Actual outcome:

Third party monitoring library override global fetch to gather data on each request.
Since createHttpLink keep a reference to fetch (code), if global fetch is instrumented after createHttpLink execution then graphql requests can't be instrumented.

How to reproduce the issue:

with a simple fetch override:

const originalFetch = window.fetch;
window.fetch = function () {
  console.log("request instrumented", arguments[0]);
  return originalFetch.apply(this, arguments);
};

if executed before ApolloClient initialization, graphql requests are logged
if executed after ApolloClient initialization, graphql requests are not logged

Versions

master

@danmayer
Copy link

This is currently impacting our ability to monitor perf related to Apollo client generated requests. It would be great to come up with a solution that would avoid brittle ordering issues.

@bignimbus
Copy link
Contributor

Hi @bcaudan, thanks for your patience! Would passing the overridden fetch function via the fetch option in HTTP Link per these docs address the issue you're describing?

@bignimbus
Copy link
Contributor

Hi @arminrosu 👋🏻 I see you reacted to the above comment - can you elaborate so that we can better understand your use case and narrow down our options here?

@arminrosu
Copy link

@bignimbus gladly, thanks for the interest.

I'm trying to set up Datadog tracing from the client down to our backend services. Datadog does this by setting some headers on GQL requests. They probably do this by wrapping browser requests and appending their headers.

It works if I initialise datadog before the apollo client. But then I started having issues with Apollo Cache. I dropped the topic for now, but that's essentially it.

I haven't tried setting a custom fetch instance, as I don't see it exported.

@bignimbus
Copy link
Contributor

Thanks @arminrosu - looking at the Datadog SDK now.

https://github.com/DataDog/browser-sdk/blob/46c51d01d497128d61532043048fde15d535c331/packages/core/src/browser/fetchObservable.ts#L41-L70

This snippet was interesting to me. It does seem like something that would be resolved by, as you said, initializing the Datadog SDK before Apollo Client.

But then I started having issues with Apollo Cache

That's also interesting and something that might be worth getting more detail on - what issues did you see? Is this a bug in Apollo Client?

@arminrosu
Copy link

That's also interesting and something that might be worth getting more detail on - what issues did you see? Is this a bug in Apollo Client?

I'll get back to you once I give this one another shot. I haven't had time to look into it closely yet.

@bignimbus bignimbus removed the 🏓 awaiting-contributor-response requires input from a contributor label Jan 18, 2023
@alessbell
Copy link
Member

Hi @arminrosu 👋 Just following up here and was curious if there are any more details you or other participants on this issue can provide to @bignimbus's question above re: downsides to initializing DD SDK before Apollo Client. Thanks!

@alessbell alessbell added 🏓 awaiting-contributor-response requires input from a contributor and removed 🍪 feature-request labels Apr 28, 2023
@arminrosu
Copy link

downsides to initializing DD SDK before Apollo Client

@alessbell thanks for checking in. No complaints from doing this. We now have it in production for a few months and everything is working fine.

@github-actions github-actions bot removed the 🏓 awaiting-contributor-response requires input from a contributor label May 1, 2023
@phryneas
Copy link
Member

I believe this issue should have been solved with #8603 and only occur in Apollo Client versions before v3.4.6.

As a result, I'm going to close this issue.
If it is still occurring in newer versions, please give this a bump so I'll reopen, or open a new issue :)

Copy link
Contributor

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
For general questions, we recommend using StackOverflow or our discord server.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jan 22, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants