These are chat archives for reactioncommerce/reaction
@loan-laux Yes, compared to e.g. Loggly, Sentry can be self-hosted, and also has great client-side error handling.
Could be great to be informed about and able to pinpoint an error even before a visitor complains.
I could get the client part to work, but Im struggling with the server.
We have the Loggrer/bunyan instance, but im not sure if Logging this would cover all errors.
Then we have ReactionError, an instance of that is sent to GraphQL Clients - Could also be helpful to log them.
Probably a matter of technical understanding of the details and I'm a bit unsure there.
So, mostly finished my Sentry Logger for client and server, just a bit rough around the edges!
It works as a plugin without touching core code, all that needs to be done is to pass two environment vars "SENTRY_CLIENT_URL" and "SENTRY_SERVER_URL" to your reaction container. (I kept those Logs separate)
As far as I can tell this should intercept all relevant logs properly, although Meteor put some obstacles in my way.
You could simply compare:
(This is both a release candidate of v2.0, but the main difference is the separate nextjs storefront while the meteor based is still included atm )
Take a look at both and decide if the latter suits your needs - e.g. search is missing and a dedicated profile page and internationalization.
Also keep in mind that there will be and where a lot of potentially breaking changes between the RC*s (well, the same was the case for stable releases)
As the latest commits that remove the customer relevant parts of the meteor project were not merged until the release of the latest rc, you could also take a current v2.0 RC
and still build upon that.
I did that with rc7 and the result is pretty stable.
Actually, more stable for my use case than 1.17 was. Some issues I had before in production didn't came anymore, although I also reimplemented some customizations and therefore can't pinpoint the root cause.
The advantage is that adding items to cart and creating orders is already converted to graphql mutations instead of meteor methods, therefore if one decides to switch to the nextjs based storefront the transition would be easier.
(GraphQL should be preferred in general over the very meteor-specific Meteor calls)