-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
feat(develop): Add docs about integrations in the SDK #11405
base: master
Are you sure you want to change the base?
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
1 Skipped Deployment
|
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.
Great to have this written down! 🥔 Found two typos + left one suggestion.
|
||
/** | ||
* This hook is only called once, even if multiple clients are created. | ||
* It does not receives any arguments, and should only use for e.g. global monkey patching and similar things. |
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 does not receives any arguments, and should only use for e.g. global monkey patching and similar things. | |
* It does not receive any arguments, and should only use for e.g. global monkey patching and similar things. |
|
||
In addition, default integrations should be well-tested. If a new integration is default, it should be tested in all supported environments and configurations to ensure it doesn't cause issues. We should not be adding new default integrations without proper testing. | ||
|
||
If an default integration creates a high volume of new data (for example a lot spans or transactions), it should be opt-in and only made default in a new major version of the SDK. This is to prevent users from being surprised by the new data and to prevent potential performance issues. In the case of spans we especially have to take care to ensure that the spans generated by a new integration don't make traces too noisy, which hurts their usefulness. |
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.
If an default integration creates a high volume of new data (for example a lot spans or transactions), it should be opt-in and only made default in a new major version of the SDK. This is to prevent users from being surprised by the new data and to prevent potential performance issues. In the case of spans we especially have to take care to ensure that the spans generated by a new integration don't make traces too noisy, which hurts their usefulness. | |
If a default integration creates a high volume of new data (for example a lot spans or transactions), it should be opt-in and only made default in a new major version of the SDK. This is to prevent users from being surprised by the new data and to prevent potential performance issues. In the case of spans we especially have to take care to ensure that the spans generated by a new integration don't make traces too noisy, which hurts their usefulness. |
- Does the integration add significant overhead to the SDK? | ||
- Does the integration create a high volume of new data? | ||
- Does the integration have potential compatibility issues with other integrations or the SDK itself? |
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 add:
- Does the integration add significant overhead to the SDK? | |
- Does the integration create a high volume of new data? | |
- Does the integration have potential compatibility issues with other integrations or the SDK itself? | |
- Does the integration add significant overhead to the SDK? | |
- Does the integration create a high volume of new data? | |
- Is the potential for issues in the integration low? | |
- Does the integration have potential compatibility issues with other integrations or the SDK itself? |
The diff is a bit noisy because of prettier formatting, but the main additions are at the very bottom, starting from
## Integrations
.This patch adds documentation around how integrations work in the SDKs. It gives some guidelines on how the public API should work, and how we approach looking at default integrations.