The following alternatives were considered to implement Sentry support:
JS-side, then error reports from Rust should be sent to JS code in order to upload them to Sentry. This raises some questions: how would Rust error reports be displayed? would they be sufficiently readable?
Rust-side, specific bindings should allow JS code to sent error reports to Rust in order to upload them to Sentry. Same questions apply as for the previous case.
Both JS & Rust then two dedicated Sentry projects will run (one for JS, one for Rust) and error reports would be uploaded separately from JS and Rust code.
The approach recommended by Sentry is to set up multiple projects for finer granularity:
You could theoretically put all your errors into a single project, as this isn't limited in sentry.io
However, setting up multiple projects to reflect your application with finer granularity helps makes errors more visible and actionable, which can have a big impact on your team's productivity.
Here are some points to consider:
If your application's source code is managed in multiple repositories, create a separate project for each repo.
If your app is made up of several micro-services, split them into projects accordingly.
If you have a monolithic codebase, set up separate projects for the backend and frontend.
Give each language its own project. For example, if your backend code contains NodeJS and Java components, separate those into two different projects.
This needs further investigation.
Context
The following alternatives were considered to implement Sentry support:
The approach recommended by Sentry is to set up multiple projects for finer granularity:
Initial POCs
Some tests were made in the following PRs:
Current status
parsec3-frontend
--notifies-->scille-frontend
parsec3-libparsec
--notifies-->scille-rust