[request feedback] Micro Frontend support

[smeubank]

Discussed in https://github.com/getsentry/sentry-javascript/discussions/4477

^{Originally posted by smeubank February 1, 2022}
We are aware of challenges customers face regarding the hub and scope model of our SDKs, and restrictions posed simply by how web browsers work globally. We want to consider ways to improve our SDK to better service impacted customers, and specifically the needs of customers with Micro Frontend style architectures. Below is a list of questions we would appreciate your feedback on, this will help guide our decision making process and engineering efforts.

1. What does your MicroFE architecture look like?
   1. Can you link us to documentation or tutorial showing exactly how your micro frontend architecture works?
   2. Are you using Webpack’s Module Federation?
   3. If yes, does your usage follow any of these examples?
2. How would they see Sentry hub and scope working?
3. Do you know of any solutions available today that solve for this? Can you link us to the documentation?
4. Would you be interested in participating in an Early Adoptor program with solutions for Hub and Scope propagation?
5. Would you be comfortable with a bundle size increase from having to configure sentry for each micro-frontend (separate init calls, creating separate hubs/clients, explicit scopes etc.)?

[mlmmn]

Hope I put this in a right place :)

Answers

Can you link us to documentation or tutorial showing exactly how your micro frontend architecture works?

There's no publicly available information unfortunately, but it basically follows the example from the webpack repo linked later on.

Are you using Webpack’s Module Federation?

Yes.

If yes, does your usage follow any of these examples?

Yes, the dynamic-system-host example.

For the record, we followed the example from this particular revision.

How would they see Sentry hub and scope working?

I'm, afraid I don't understand the question.

Do you know of any solutions available today that solve for this? Can you link us to the documentation?

No known solutions afaik.

Would you be interested in participating in an Early Adoptor program with solutions for Hub and Scope propagation?

Yes.

Would you be comfortable with a bundle size increase from having to configure sentry for each micro-frontend (separate init calls, creating separate hubs/clients, explicit scopes etc.)?

It depends on how big such increase would be. Code-splitting is always welcome whenever feasible :)

---

Architecture details

Within our React based host-remote architecture, we developed the following solution for managing Sentry with federated modules. The assumption is that the remote app means an app that is developed and maintained by an independent team. Teams are free to use any monitoring tools they wish, although as of today everyone does use Sentry indeed.

Within the Sentry's host app project we either assign teams based on tags sent with an event or via rules set in the web interface. This works to some extent, but does not allow federated apps teams to take advantage of source maps as this requires an independent Sentry project and thus...

... a dedicated Sentry client with own dsn url and release tags. Below I'll do my best to describe our way to workaround current Sentry limitations.

Host app

The host app has its own Sentry.init() call. This obviously works for every case as described in the docs (particularly the integrations).

Sentry.init({
  dsn: "https://***@***.ingest.sentry.io/***",
  release: getReleaseTag(),
  allowUrls: sentryAllowUrls,
  denyUrls: sentryDenyUrls,
  ignoreErrors: sentryIgnoreErrorsList,
  beforeSend: function (event: Sentry.Event, hint: Sentry.EventHint) {
    if (beforeSendFilters.some((filter) => filter(event, hint))) {
      return null;
    }

    return event;
  },
  attachStacktrace: true,
  sampleRate: 0.1,
  integrations: [new TracingIntegrations.BrowserTracing()],
  tracesSampleRate: 0.2,
});

The federated module loading function sits in a dedicated module and is ready to be reused

export const getRemoteModule = async (
  remote: AvailableRemotes,
  module: string
): Promise<{ default: any }> => {
  await __webpack_init_sharing__("default");

  const container = window[remote];

  await container.init(__webpack_share_scopes__.default);

  // If anything throws an error during initialization of remote module, it happens right here
  const factory = await window[remote].get(module);

  return factory();
};

To actually get a remote React component we use a useRemoteComponent hook which is mostly based on useDynamicScript from Webpack's example. The relevant addition is that we wrap such component within its own RemoteComponentErrorBoundary component like so:

<RemoteComponentErrorBoundary remote={remote}>
  <Suspense fallback={<Loader />}>
    <RemoteComponent {...props} />
  </Suspense>
</RemoteComponentErrorBoundary>

export class RemoteComponentErrorBoundary extends React.Component<
  Props,
  State
> {
  async componentDidCatch(error: Error) {
    const { remote } = this.props;

    try {
      // Attempt to get remote logger
      const remoteLogger: RemoteLogger = (
        await getRemoteModule(remote, "./logger")
      ).default;

      remoteLogger.captureException(error);
    } catch {
      // Remote logger does not exist, use host's logger and tag correct team
      const team = mapRemoteToTeam[remote];

      logger.captureException(error, {
        ...(team && { team }),
      });
    }
  }
}

You can clearly see that we have introduced a kind of a "contract": if a team wants to use their own Sentry client, they're allowed to do so by exposing a ./logger entry that follows given interface.

We assume that this should be used only for initialization exceptions (thus the fallback for host's logger) and for the actual logging the remote app is encapsulated within own error boundary component.

Remote app

Things get much much more complicated in the remote app realm. Since Sentry's multi client support is limited, we have somewhat reverse-engineered some integrations implementation to bring the most important back.

// Sentry integrations (breadcrumbs, user agent and so on) currently do not work when using multiple clients (meaning
// initializing Sentry like above, not by Sentry.init()). This is said to be fixed in Sentry client v7 according to the
// GitHub issue https://github.com/getsentry/sentry-javascript/issues/2732
// Until v7 is released, some functionality like breadcrumbs and user agent info have to be manually recreated.
const linkedErrors = new Integrations.LinkedErrors();
const dedupe = new Integrations.Dedupe();
let previousEvent: Event;
const client = new BrowserClient({
  dsn: "https://***@***.ingest.sentry.io/***",
  release: getEnv().RELEASE,
  defaultIntegrations: false, // Won't work with multiple client setup anyway
  attachStacktrace: true,
  sampleRate: 0.1,
  normalizeDepth: 6,
  beforeSend(event, hint) {
    // Recreating Dedupe integration to ignore duplicate events
    if (
      shouldIgnoreEvent(event) ||
      // @ts-ignore _shouldDropEvent is protected
      dedupe._shouldDropEvent(event, previousEvent) // eslint-disable-next-line no-underscore-dangle
    ) {
      return null;
    }

    previousEvent = event;

    // Recreating LinkedErrors integration (for React component stack trace)
    // @ts-ignore _handler is protected
    // eslint-disable-next-line no-underscore-dangle
    const enrichedEvent = linkedErrors._handler(event, hint) as Event;

    // Recreating UserAgent integration
    if (window.navigator && window.location && window.document) {
      const url = enrichedEvent.request?.url || window.location?.href;
      const { referrer } = window.document || {};
      const { userAgent } = window.navigator || {};

      const headers = {
        ...enrichedEvent.request?.headers,
        ...(referrer && { Referer: referrer }),
        ...(userAgent && { "User-Agent": userAgent }),
      };
      const request = { ...(url && { url }), headers };

      enrichedEvent.request = { ...enrichedEvent.request, ...request };
    }

    enrichedEvent.breadcrumbs = enrichedEvent.breadcrumbs
      ?.filter((breadcrumb) => !shouldIgnoreBreadcrumb(breadcrumb))
      .sort((a, b) => {
        if (a.timestamp && b.timestamp) {
          return a.timestamp - b.timestamp;
        }

        return 0;
      });

    return enrichedEvent;
  },
});
const hub = new Hub(client);
const getBreadcrumbs = () =>
  // Obtain breadcrumbs from global Sentry hub instance in host app
  // @ts-ignore _breadcrumbs is protected
  getCurrentHub().getScope()._breadcrumbs ?? []; // eslint-disable-line no-underscore-dangle

// The actual client that is exported
export const sentry = {
  addBreadcrumb: (breadcrumb: Breadcrumb, hint?: BreadcrumbHint) =>
    hub.addBreadcrumb(breadcrumb, hint),
  setUser: (user: User) => hub.setUser(user),
  setTags: (tags: Tags) => hub.setTags(tags),
  captureGraphQLError: (
    error: GraphQLError,
    captureContext?: CaptureContext
  ) => {
    hub.run((currentHub) => {
      currentHub.withScope((scope) => {
        scope.setContext("GraphQLError", {
          ...(error.path && { path: error.path }),
          code: error.extensions?.code,
        });
        scope.setFingerprint(
          [
            error.message,
            error.extensions?.code,
            ...(error.path ? error.path.map(String) : []),
          ].filter(Boolean)
        );

        currentHub.captureMessage(error.message, Severity.Error, {
          captureContext,
        });
      });
    });
  },
  captureException: (
    exception: Error,
    captureContext?: CaptureContext & { componentStack?: string }
  ) => {
    const breadcrumbs = getBreadcrumbs();

    hub.run((currentHub) => {
      currentHub.withScope((scope) => {
        breadcrumbs.forEach((breadcrumb) => {
          scope.addBreadcrumb(breadcrumb);
        });

        const error =
          exception instanceof Error
            ? exception
            : new Error((exception as Error).message || "Unknown error");

        if (captureContext?.componentStack) {
          // Copied from https://github.com/getsentry/sentry-javascript/blob/master/packages/react/src/errorboundary.tsx
          const errorBoundaryError = new Error(error.message);

          errorBoundaryError.name = `ReactErrorBoundary: ${errorBoundaryError.name}`;
          // @ts-ignore used by sentry
          errorBoundaryError.stack = captureContext.componentStack;
          // @ts-ignore used by sentry
          error.cause = errorBoundaryError; // eslint-disable-line no-param-reassign
        }

        currentHub.captureException(error, {
          originalException: error,
          captureContext,
        });
      });
    });
  },
  captureMessage: (
    message: string,
    level?: Severity,
    captureContext?: CaptureContext
  ) => {
    const breadcrumbs = getBreadcrumbs();

    hub.run((currentHub) => {
      currentHub.withScope((scope) => {
        breadcrumbs.forEach((breadcrumb) => {
          scope.addBreadcrumb(breadcrumb);
        });

        currentHub.captureMessage(message, level, { captureContext });
      });
    });
  },
};

Summary

As you can see, we have reimplemented four particularly important integrations:

• Breadcrumbs
• LinkedErrors (for React stack)
• Dedupe
• UserAgent

In an ideal setup, we'd like to have this integrations available out of the box in the remote app. In the remote app we don't care about uncaught exceptions since it's host's job to catch those.