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

Recommended way to use micro-frontends with Sentry JS SDK #7622

Closed
AbhiPrasad opened this issue Mar 27, 2023 · 8 comments · Fixed by getsentry/sentry-docs#6754
Closed

Recommended way to use micro-frontends with Sentry JS SDK #7622

AbhiPrasad opened this issue Mar 27, 2023 · 8 comments · Fixed by getsentry/sentry-docs#6754
Assignees

Comments

@AbhiPrasad
Copy link
Member

AbhiPrasad commented Mar 27, 2023

After soliciting feedback about micro-frontends from a variety of users and getting issues about it, we need to take steps to define a solid strategy around using Sentry with micro-frontends.

The most common thing we heard is that users want to be able to send to different sentry projects from a single web application.

There are some things we heard mixed messaging about, that folks were both for and against.

  • Isolating breadcrumbs to an individual micro-frontend
  • Conditionally requiring different automatic instrumentations based on micro-frontend module
  • Exact behavior around performance monitoring with multiple micro-frontends

In addition, Browser JavaScript does not provide any async storage mechanism, so there is no way for us to properly isolate data to an set of async function calls.

Based on this, our recommended solution for micro-frontends is going to be as the following (until we can make larger SDK refactors for more advanced behaviours - requires a new major version):

1 web application means 1 call to Sentry.init, and we will provide an API so that users can make decisions on what events to send to what project. We made some early attempts at exploring this already.

// Just an example.
Sentry.init({
  // replays/sessions/transactions all to go MAIN_DSN
  dsn: 'MAIN_DSN';
  // only works with errors
  integrations: [new Multiplexer([
    {
      dsn: '__DSN_ONE__',
      matcher: (event) => event.tags.user === 'VERY IMPORTANT USER';
    },
    {
      dsn: '__DSN_TWO__',
      matcher: (event) => GLOBAL_PER_MODULE_TYPE === 'MODULE_TWO';
    },
  ])];
});

Then in the docs we add a one-pager about our recommended way to use micro-frontends.

This way is very opinionated on purpose - let's make sure we have a confident answer to give to users instead of just giving half-measures.

@AbhiPrasad AbhiPrasad self-assigned this Mar 27, 2023
@AbhiPrasad AbhiPrasad removed their assignment Apr 5, 2023
@Sinetheta
Copy link

Thanks @AbhiPrasad this would be very helpful for projects that are okay with a single host app that performs the init and has knowledge of child apps.

replays/sessions/transactions all to go MAIN_DSN

I wonder if there will be any way to provide linking from error to Replay. It's a very minor concern, Errors are far more important. But will the replayId still be present on the error events? Or should tracing be done using another tag like trace.id?

@AbhiPrasad
Copy link
Member Author

Since under the hood we are running with one sentry client we'll be able to make those associations between errors/replays and errors/traces - and the product does not care if these are in different projects.

@amccloud
Copy link

amccloud commented Apr 6, 2023

@AbhiPrasad I know you're trying to find a limited approach to start with. I'm not confident this Mutiplexer approach work for federated micro-frontends, where one or many host apps are unaware of the micro-frontends they depend on. A host also shouldn't know which micro-frontends have a sentry DSN to multiplex to. Ideally each micro-frontend would bring its own DSN and matcher.

@AbhiPrasad
Copy link
Member Author

@amccloud We can easily update the API so that new matchers can be added on demand, so then it doesn't all have to be defined on Sentry.init.

@AbhiPrasad
Copy link
Member Author

AbhiPrasad commented Apr 25, 2023

In favour of a slightly cleaner API, @timfish helped us build a multiplexing transport instead: #5185

The PR contains some examples of how this works.

Re #7622 (comment) - this will unfortunately be a little more manual, but you can accomplish this via: #7926 (comment)

For next steps, we want to release this, create some initial docs, and then start experimenting with module federation to create some examples for y'all to take a look at. Thanks for your patience everyone!

@AbhiPrasad
Copy link
Member Author

I created some docs in getsentry/sentry-docs#6754 since the makeMultiplexedTransport was released with our latest release 7.50.0: https://github.com/getsentry/sentry-javascript/releases/tag/7.50.0

@AbhiPrasad
Copy link
Member Author

We've shipped the above in some docs: https://docs.sentry.io/platforms/javascript/configuration/micro-frontend-support/

Next step is for us to add some docs around using webpack module federation, maybe we even add some logic to our sentry webpack plugin to make it easier.

@william-hotmart
Copy link

@AbhiPrasad great work!
Do you know when the docs for use in module federation micro frontends will be available?

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

Successfully merging a pull request may close this issue.

5 participants