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

Sub apps support #1280

Open
HassanAzzam opened this issue Jan 20, 2022 · 10 comments
Open

Sub apps support #1280

HassanAzzam opened this issue Jan 20, 2022 · 10 comments

Comments

@HassanAzzam
Copy link

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
Copy link
Member

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
Copy link
Author

That's cool! Thanks for your efforts!

@elenasch
Copy link

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

@jwallet
Copy link

jwallet commented Mar 31, 2022

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
Copy link

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

@bcaudan
Copy link
Contributor

bcaudan commented Oct 18, 2022

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
Copy link

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
Copy link

@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
Copy link

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
Copy link

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

8 participants