🙏 Multiple Instances of Datadog on Third Party Sites

[chrismyer]

What are you trying to achieve and what is your issue? Please describe.
We use Datadog @datadog/browser-logs and @datadog/browser-rum v6 in our React based SDK that runs on various host sites that we do not control, some of which also use Datadog. If our version and the host site's version of Datadog conflict, then one will overwrite the other's global DD_LOGS and DD_RUM vars.

We also receive this error:
Datadog Browser SDK: SDK is loaded more than once. This is unsupported and might have unexpected behavior.

Describe the solution you'd like
We would like a solution for using Datadog in a React frontend SDK that can be run on other third party sites that also use Datadog.

Describe alternatives you've considered
We have searched through the Datadog docs and issues and have only come across this snippet on micro frontends, but it doesn't seem to solve our issue.

[dstepp-indeed]

At Indeed we have encountered essentially the same issue where we want to include some of our code on 3rd party sites, some of which already use DataDog, and want our own DD RUM logging on that code running on those pages (while disturbing the page's existing DD logging as little as possible).

We are currently working around this issue by having forked this repo and building our own custom package that renames the global window.DD_RUM and a few other globals to a new name for the 2nd instance such as window.INDEED_DD_RUM. Generally speaking, it works. A few features currently cannot be properly separated between 2 client instances, such as session recording or interaction tracking. And uncaught errors are logged by both instances unless you set up explicit filtering, so there can be some cross-pollution of the data. But the general data gathering such as views and actions and error events works just fine with two dd rum client instances active on the same page, and the explicit action/error log data between the two are separate, so long as the globals are isolated from each other as described.

This works for our purposes, but it's a hack and has all the drawbacks you would expect, such as, we need to pull/rebase the source code from here and repackage our fork manually every time we want to upgrade the second DataDog client. We really wish there were an officially supported way to have two DataDog RUM client instances active on the same page at the same time. DD seems to be working to support two services within the same application ID active at the same time as a way of trying to support micro-frontends, but that does not fit our use case. As stated, we are talking about two totally separate application IDs active on the same page at the same time, each wanting the ability to send up logs to DD servers (or a proxy) without being mixed with the logs of the other.

[chrismyer]

Thanks! Thats a really interesting option. And yes the micro-frontend option doesn't fit our use-case either. We are currently getting around this problem by creating a mini app inside an iframe that just includes Datadog. We then use postMessage from our normal app to send over any events to the iframed Datadog mini app. Datadog can also communicates back with our normal main app with postMessage. This way, no namespace collisions occur as both Datadog instances are kept completely separate. It's certainly not an ideal solution and has drawbacks.

[dstepp-indeed]

@chrismyer We also tried implementing that approach, putting the DD RUM client in an iframe sandbox and communicating to it using postMessage. That worked, too, but we found it cumbersome and rolled it back. We had to meticulously send every DD RUM event across the postMessage channel, and it only really worked well for events that our code manually emitted such as actions and errors; it didn't work as well for events emitted from the internals of the dd rum client itself, like views, resource fetching, long tasks, or session replays. We found that we were having to hack more and more to be able to detect and capture these events to send them across the postMessage pipe, and we felt we were fighting DataDog client too much, so ultimately we went with the other approach. * I was also concerned about performance, since our pages are somewhat bloated and send up to hundreds of DD RUM event messages per page view, so that's a lot of postMessages for the browser to manage.

[mormubis]

Hi @chrismyer,

Thank you for raising this. We’re exploring ways to improve scenarios like micro-frontends. While we don’t have something to share, this request is on our radar and connected to related discussions around multi-tenant and multi-instance usage. I’ll keep you updated on any progress or potential workarounds as they become available.

[chrismyer]

@dstepp-indeed thanks for this feedback. Our iframe solution hasn't been rolled out yet and so hasn't been battle tested yet. We'll look into the other less optimal solution of forking, which is probably a better fit for us as well.

Thank you @mormubis for putting this issue on Datadog's radar. It would be awesome to be able to use Datadog out of the box for usage in sdks that are placed on third party sites that also include Datadog.

[dstepp-indeed]

Honestly I would be quite happy with a band-aid version of support for this feature, where maybe in the datadogRum.init options I could pass a custom name to give the DD_RUM global. Something like:

datadogRum.init({
    ...,
    globalName: 'MY_DD_RUM'
});

And then it would use window.MY_DD_RUM instead of window.DD_RUM for that instance of the library. I realize that some features would not work perfectly; maybe it could be undocumented or listed as a partial workaround or something, but that would still be better than having to fork the browser-sdk and search/replace DD_RUM with another name every time we want to upgrade. Thanks for the consideration.