Sub apps support

[HassanAzzam]

We're using React with Single SPA in our stack, each sub app refers to a specific service on DataDog. How can we pass the service name for each sub app to the collected data?

[BenoitZugmeyer]

Hello @HassanAzzam

This is not doable right now, as the service is configured once during init. But we are currently working on this topic, and we'll implement a solution in the coming weeks. We'll keep you up-to-date by commenting on this issue.

[HassanAzzam]

That's cool! Thanks for your efforts!

[elenasch]

What is the status of this feature?
My team is also very interested in using it

[jwallet]

in the other post #1225 @bcaudan said that we won't be able to use more than one instance of the sdk, but how will we be able to have the proper stack trace unminified (with source maps pushed with datadog-ci) if we are still required to provide the version of the micro app if the micro app only knows its own version.

I currently use a workaround, I use multiple sdk instance, every module is an app as well as our sidebar, so two instances can live at the same time (sidebar + 1 mounted module), I use beforeSend and valid if the stack trace hit in my source code otherwise I return false because the other module might log it, I prevent the wrong one to log it because it reports an error with a minified stack trace, with the wrong service and the wrong release-version

datadogRum.init({
  // minifiedPathPrefix: '/menu/', <-- something like datadog-ci uses, so it logs only errors from /static/js/menu/entrypoint.min.js
  beforeSend: (_, ctx) => {
      const { origin } = window.location;
      // using origin since the first stack trace line will show a file path, probably entrypoint.min.js (hosted on our domain)
      // otherwise we don't want to log it since it will be incompatible with our uploaded sourcemap
      // or another module already reported the same error
      // generic error are reported via datadog logs on the base app.
      const firstStackTraceAppearance = _get(ctx, "error.stack", "").indexOf(origin);
      // ignore errors outside of own context (already reported)
      return _get(ctx, "error.stack", "")
        .substring(origin.length + firstStackTraceAppearance)
        .startsWith("/menu");
    },
    version: SAME_AS_RELEASE_VERSION_DATADOG_CI,
    trackInteractions: true // only with our menu app, to prevent multiple replay sessions
});

it would be nice to have a toggle feature that already do something like that. I cannot use a singleton because every module has its own version tag. When using datadog-ci sourcemaps upload to upload sourcemap to datadog you already ask for --minified-path-prefix (which already matches the micro-app) so why does the RUMLogger does not ask for the same thing. It would be nice to have a way to log only errors from its own context and related to the sourcemap we uploaded to datadog.

datadog-ci sourcemaps upload ./build --service=menu --minified-path-prefix=/menu/ --repository-url=https://bitbucket.org/project/menu --release-version=$RELEASE_VERSION
>> https://sub.domain.com/static/js/menu/entrypoint.min.js
datadog-ci sourcemaps upload ./build --service=inventory --minified-path-prefix=/inventory/ --repository-url=https://bitbucket.org/project/inventory --release-version=$RELEASE_VERSION
>> https://sub.domain.com/static/js/inventory/entrypoint.min.js
datadog-ci sourcemaps upload ./build --service=invoicing --minified-path-prefix=/invoicing/ --repository-url=https://bitbucket.org/project/invoicing --release-version=$RELEASE_VERSION
>> https://sub.domain.com/static/js/invoicing/entrypoint.min.js

[PaulKujawa]

Any updates on that, @BenoitZugmeyer? We also use Single-SPA and want to switch from Sentry to Datadog RUM in FE 🙏

[bcaudan]

Hello,

Currently, we are only supporting cases where only one sub app can be active on a single page view.
service and version should be used to identify the different sub apps and their corresponding versions in order to properly link with Datadog source code integration.

You can change the active sub app by using the startView API (more details):

datadogRum.startView({
  name: 'checkout',
  service: 'purchase',
  version: '1.2.3'
})

It allows to support cases where one sub-app correspond to one url route.

In the fullness of time, we would like to have support for multiple sub apps on a single page view but it is not in our current priorities.
The main challenge on this topic is the attribution of the different events to the correct service, especially error events for which the service is used for the unminifying of the stack trace.

We will let you know here if we make progress on this topic.

[colinchilds]

Just putting my company's use case in here so I can follow progress. We also use Single SPA with up to a half dozen or so apps active at once. We are currently trying to migrate away from Sentry for error logging, but ran into this snag with the Datadog SDK. Currently, with Sentry we have all our browser logs sent up to a single "service", and just log which apps are active. One of the biggest things missing from DD that Sentry has is that it actually works with multiple source maps.

[PaulKujawa]

@colinchilds are you sure DD does not support multiple source maps?

@bcaudan essentially proposed exactly what you have over in #1777 (comment). I explained further down the thread how I think it might be feasible. I just have some doubts about the best-case outcome even.

[colinchilds]

I'm sure it may be feasible. but we already have a simple solution with Sentry. So until DD properly supports microfrontends, we'll unfortunately just have to use what we've got. We'd love to move everything over to DD but they seem to be lacking in this specific area.

[pedro-canelas]

Hello
I'm currently trying to track multiple views. Using the startView works well for the first view, but each time we use a new startView, it cumulates with the previous one. Is there a way of closing the view and starting a new one?

[mellis481]

I feel obligated to add to this thread... the main issue I have with the RUM SDK implementation which has made integrating it into our microfrontend-based solution challenging is that it uses a singleton RUM object which is adding as a prop to the window object which is basically a universally-agreed upon bad practice.