You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have a question regarding strategies to initialise Sentry SDK in microfrontends architecture. I have read the corresponding docs section and more, however I still have some open questions, so I hope to obtain some knowledge here.
High level overview of a setup we are working with:
We have a number of React applications.
Each app is hosted on a separate route, i.e. org.com/product-a, org.com/product-b, etc.
We also have a platform code, which mounts a corresponding React app based on the route.
Each app has its own Sentry project.
Currently, every React app is calling Sentry.init with its own DSN key when the app is mounted. However, our users can navigate between the products (i.e. go from product A to product B). Since this navigation involves mounting a new MFE, Sentry.init can be called twice.
The documentation linked above states the following:
In all cases Sentry.init() must never be called more than once, doing so will result in undefined behavior.
Thus I was wondering what would be a reasonable Sentry.init strategy in our scenario. We mainly call Sentry.init when a corresponding microfrontend is mounted to ensure that the runtime errors from the newly mounted app are routed to the correct project. (Note: however we are have a significant amount of misrouted issues, i.e. runtime issue from project A report to project B and vice versa).
Is there a way for us to ensure that calling Sentry.init when a new app is mounted would not inflict unknown behaviour? Perhaps something similar to a concept of the useEffect hook in React, where we can return a "cleanup" function. I guess if any sort of "re-initialise" mechanism can be implemented, we could keep calling Sentry.init on app mount.
Alternatively, I imagine we could call Sentry.init once, before any microfrontend app is mounted, and then with custom transport we navigate issues to the corresponding Sentry projects? I wonder if in this scenario we could still benefit from having multiple Sentry projects and if Replays, performance tracing data and other data can be properly distributed between Sentry projects...
Please let me know what you think. I would be happy to hear any inputs on this topic. Thank you!
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Hi all,
I have a question regarding strategies to initialise Sentry SDK in microfrontends architecture. I have read the corresponding docs section and more, however I still have some open questions, so I hope to obtain some knowledge here.
High level overview of a setup we are working with:
org.com/product-a
,org.com/product-b
, etc.Currently, every React app is calling
Sentry.init
with its own DSN key when the app is mounted. However, our users can navigate between the products (i.e. go from product A to product B). Since this navigation involves mounting a new MFE,Sentry.init
can be called twice.The documentation linked above states the following:
Thus I was wondering what would be a reasonable
Sentry.init
strategy in our scenario. We mainly callSentry.init
when a corresponding microfrontend is mounted to ensure that the runtime errors from the newly mounted app are routed to the correct project. (Note: however we are have a significant amount of misrouted issues, i.e. runtime issue from project A report to project B and vice versa).Is there a way for us to ensure that calling
Sentry.init
when a new app is mounted would not inflict unknown behaviour? Perhaps something similar to a concept of theuseEffect
hook in React, where we can return a "cleanup" function. I guess if any sort of "re-initialise" mechanism can be implemented, we could keep callingSentry.init
on app mount.Alternatively, I imagine we could call
Sentry.init
once, before any microfrontend app is mounted, and then with customtransport
we navigate issues to the corresponding Sentry projects? I wonder if in this scenario we could still benefit from having multiple Sentry projects and if Replays, performance tracing data and other data can be properly distributed between Sentry projects...Please let me know what you think. I would be happy to hear any inputs on this topic. Thank you!
Beta Was this translation helpful? Give feedback.
All reactions