Skip to content

Commit

Permalink
Update micro-frontends.mdx (#12040)
Browse files Browse the repository at this point in the history
* Update micro-frontends.mdx

Update micro frontend docs based on user feedback.

* Update docs/platforms/javascript/common/best-practices/micro-frontends.mdx

* Update docs/platforms/javascript/common/best-practices/micro-frontends.mdx

* Update docs/platforms/javascript/common/best-practices/micro-frontends.mdx

* Update docs/platforms/javascript/common/best-practices/micro-frontends.mdx

* Update docs/platforms/javascript/common/best-practices/micro-frontends.mdx

Co-authored-by: Lukas Stracke <[email protected]>

* Update docs/platforms/javascript/common/best-practices/micro-frontends.mdx

Co-authored-by: Lukas Stracke <[email protected]>

* Update docs/platforms/javascript/common/best-practices/micro-frontends.mdx

Co-authored-by: Alex Krawiec <[email protected]>

* Update docs/platforms/javascript/common/best-practices/micro-frontends.mdx

---------

Co-authored-by: Lukas Stracke <[email protected]>
Co-authored-by: Alex Krawiec <[email protected]>
  • Loading branch information
3 people authored Dec 5, 2024
1 parent 007f1da commit c812eb2
Showing 1 changed file with 17 additions and 21 deletions.
38 changes: 17 additions & 21 deletions docs/platforms/javascript/common/best-practices/micro-frontends.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -21,22 +21,22 @@ keywords:
"module metadata",
]
---
<Alert>
To ensure the Sentry JavaScript SDK works with your micro frontends, make sure all micro frontends that import from a `@sentry/*` package are using the same version of the Sentry SDK.
</Alert>

If your frontend includes JavaScript bundles from multiple sources with
different release cycles, you may want to identify these or route events to specific projects. This is especially useful if you've set up [module federation](https://module-federation.github.io/) or a similar frontend architecture.
If your app uses micro frontends, it’s very useful to be able to track which one an error is coming from. To do this with Sentry, you can create either an automatic or a manual setup where you send events to separate Sentry projects representing each of your micro frontends. This makes it easier to see what’s going wrong and where, helping you track issues and fix them faster, especially in complex frontend architectures.

Below we offer two approaches.
Below you'll find setup instructions for both an automatic and a manual way to route errors to different Sentry projects.

<Note>
In all cases `Sentry.init()` must never be called more than once, doing so
will result in undefined behavior.
</Note>

## Automatically Route Errors to Different Projects Depending on Module
## Automatically Route Errors to Different Projects

`ModuleMetadata` and `makeMultiplexedTransport` can be used together to automatically route
events to different Sentry projects based on the module where the error
occurred.
`ModuleMetadata` and `makeMultiplexedTransport` can be used together to automatically route events to specific Sentry projects that represent your micro frontend services. Events will be routed once the service where the error occurred has been identified, ensuring errors are tracked in the correct project.

<Note>
<ul>
Expand All @@ -49,11 +49,13 @@ occurred.
</ul>
</Note>

First, to identify the source of an error, you must inject metadata that helps identify
To identify the source of an error, you must first inject metadata that helps identify
which bundles were responsible for the error. You can do this with any of the
Sentry bundler plugins by enabling the `moduleMetadata` option. The example
below is for Webpack, but this is also supported in Vite, Rollup, and esbuild.

**Install the below code snippet in your micro frontend:**

```javascript
// webpack.config.js
const { sentryWebpackPlugin } = require("@sentry/webpack-plugin");
Expand All @@ -76,7 +78,7 @@ which bundles may be responsible for an error. Once the destination is determine
store it as a list of DSN-release pairs in `event.extra[MULTIPLEXED_TRANSPORT_EXTRA_KEY]`
for the multiplexed transport to reference for routing.

In practice, here is what your Sentry initialization should look like:
**Install the below code snippet in your host:**

```javascript
import {
Expand Down Expand Up @@ -138,14 +140,13 @@ will return matches for errors, transactions, and replays.
## Manually Route Errors to Different Projects
If, however, you would like to have more control over the routing of errors to the point
where you explicitly specify the destination for each individual `captureException`,
you can do that with the more advanced interface multiplexed transport offers.
If you want more control to be able to explicitly specify the destination for each individual `captureException`,
you can use the more advanced interface multiplexed transport offers.
<Note>Requires SDK version `7.59.0` or higher.</Note>
The example below uses a `feature` tag to determine which Sentry project to
send the event to. If the event does not have a `feature` tag, we send it to the
send the event to. If the event doesn't have a `feature` tag, we send it to the
fallback DSN defined in `Sentry.init`.
```js
Expand Down Expand Up @@ -176,14 +177,9 @@ init({
You can then set tags/contexts on events in individual micro-frontends to decide which Sentry project to send the event to as follows:
<Note>
It is important to always use a local scope when setting the tag (either as
shown below or using{" "}
<PlatformLink to="/enriching-events/scopes/#local-scopes">
withScope documentation
</PlatformLink>
). Using a global scope e.g. through `Sentry.setTag()` will result in all
subsequent events being routed to the same DSN regardless of where they
originate.
It's important to always use a local scope when setting the tag (either as shown below or using{" "} <PlatformLink to="/enriching-events/scopes/#local-scopes">
withScope documentation </PlatformLink>). Using a global scope, for example, through `Sentry.setTag()` will result in all subsequent events being routed to the
same DSN regardless of where they originated.
</Note>
```typescript
Expand Down

0 comments on commit c812eb2

Please sign in to comment.