Error Tracking with single-spa / micro frontends

[PaulKujawa]

Hey folks,

We try to get Datadog RUM working with micro-frontends, where we have multiple micro frontend applications running on one page.

The setup we've tried:

• the single HTML file shared by all apps instantiates one BrowserSdk instance with one Datadog application & service
• each mfe application is reflected as a service on Datadog and uploading sourcemaps for its releases and service
• we disabled automated view tracking and instead each mfe app dispatches those manually to override the service attribute

But this does not seem to support multiple services on one page load, because the application stats, bundling all services, would be screwed as one page load emits multiple view events and events descending the view event, like error events, would be linked to the view event last dispatched on that page.

So when one page loads 3 or 4 applications, each reflected as a service on DD, we would only be able to properly monitor one of these. But it seems worse for uncaught, asynchronous errors bubble up to window.onerror where they would become logged by the connected service, where they however do not fit in and hence create noise.

This issue relates to #1225 and #1280

[bcaudan]

Hello @PaulKujawa,

Your analysis is good, you can have a look at #1280 (comment) for our current state around sub apps.

In your case, I'd recommend you to try to:

• only have a single service representing all mfe applications
• if mfe applications can have different versions, use a unique version composing the versions of the different mfe applications (ex: appA@v123 / appB@v456 => singleService@v123+456)

Using the same service and version for SDK configuration and upload of source maps would allow to link the collected error to their source code.

[fsmaia]

Hello @PaulKujawa,

Your analysis is good, you can have a look at #1280 (comment) for our current state around sub apps.

In your case, I'd recommend you to try to:

• only have a single service representing all mfe applications
• if mfe applications can have different versions, use a unique version composing the versions of the different mfe applications (ex: appA@v123 / appB@v456 => singleService@v123+456)

Using the same service and version for SDK configuration and upload of source maps would allow to link the collected error to their source code.

This would involve some very undesirable and hard-to-achieve requirements:

• The container app would have to know all the MF versions (to be able to compose the combined version)
• When every app (container or MF) has a new deployment, it should redeploy the sourcemaps of all the apps, so the new combined version doesn't lose the other application sourcemaps

[bcaudan]

Indeed, it is the only workaround I can think of as long as we don't have support for multiple sub apps on a single page view.

[fsmaia]

Is it possible to change the service inside datadogRum.init#beforeSend? If we can detect the proper application using the triggered error info (e.g. filename from the stack trace), it would work just fine too.

[fsmaia]

Another solution is to make Datadog able to autofetch the sourcemaps if they are public.

When a .js file has a source map, the map file is usually indicated at the end of the file, in the #sourceMappingUrl. Another heuristic is to add .map suffix to the file and try to fetch it.

[bcaudan]

Is it possible to change the service inside datadogRum.init#beforeSend?

It is not something that we support for now, we may consider it but that would require more thoughts on our side.

Another solution is to make Datadog able to autofetch the sourcemaps if they are public.

Do you mean on the SDK side? If yes, it is probably not something that we will want to invest on, given the potential complexity and performance impact.

[fsmaia]

Do you mean on the SDK side? If yes, it is probably not something that we will want to invest on, given the potential complexity and performance impact.

I mean on the Datadog's server side. After an error is sent, it is processed, right? The error stack contains a file (at <file>), and this file may end with a #sourceMappingUrl, and this file could be scanned/uploaded along the processing, internally.

[bcaudan]

I have reached out to the the team responsible of the source code integration, retrieving the publicly exposed source maps is something that they have considered, it is not in their current priorities though.

[PaulKujawa]

Hello @PaulKujawa,
Your analysis is good, you can have a look at #1280 (comment) for our current state around sub apps.
In your case, I'd recommend you to try to:

• only have a single service representing all mfe applications
• if mfe applications can have different versions, use a unique version composing the versions of the different mfe applications (ex: appA@v123 / appB@v456 => singleService@v123+456)

Using the same service and version for SDK configuration and upload of source maps would allow to link the collected error to their source code.

This would involve some very undesirable and hard-to-achieve requirements:

• The container app would have to know all the MF versions (to be able to compose the combined version)
• When every app (container or MF) has a new deployment, it should redeploy the sourcemaps of all the apps, so the new combined version doesn't lose the other application sourcemaps

single-spa has a K8 service called importmap-deployer what maintains the central importmap.json, referencing the latest JS files of each application. Communication between CI/CD pipelines of each app and this service runs over an HTTP API. One might be able to extend this API to also transmit the sourcemaps and release version. It could then either directly update DD or delegate it to some other K8 service.

But @fsmaia is right, question would be how the browser runtime would receive this updated, composed version. The service taking on the role of the importmap-deployer would need to rebuild some JSON file with the new composed version, that could be loaded by the container app like it loads the importmap.json file.

Possible, but quite some workaround.

/edit: Also, going with one service only would mess with the issue to release mapping and make it more cumbersome to monitor statistics based on applications.

[7E6D4309-D2A9-4155-9D4F-287B8CDA14C1]

For reference, Sentry supports automatically fetching sourcemaps. This is our biggest blocker for migrating off of Sentry to Datadog.

https://docs.sentry.io/platforms/javascript/sourcemaps/

[PaulKujawa]

@bcaudan would it be possible to... do the merge & update of individual sourcemaps on Datadog side?
Lets say we have 3 apps, and one "composed" version with 3 source maps.

Now, one application got updated. We would like to create a new version, but only provide the sourcemaps of the updated app. Datadog would then take over the other sourcemaps from the latest release and ideally even compose the new version. This way we don't need to introduce a central Hub on client side. Maybe it could be an optional flag one could set in the CLI when pushing sourcemaps for a service. I know this is very specific and probably needs some abstraction, but perhaps be a compromise for demand and offer for the time being?

---

@7E6D4309-D2A9-4155-9D4F-287B8CDA14C1, can you please explain how fetching public sourcemaps helps you with the micro frontend setup? Would you not still need to compose one version in a central place? And publishing sourcemaps is not considered a best industry practise

[bcaudan]

@PaulKujawa thanks for the suggestion, we'll keep this use case in mind and evaluate possible approaches when we will prioritise this topic.

[robmosca]

We have the same problem. We are going to move to microfrontends using single-spa and will have to sacrifice sourcemaps in Datadog RUM, for this. It would be great if Datadog could provide support for this use case!