Support for Shopify's Hydrogen Framework

[smeubank]

Discussion

The wait is over for Shopify's new JavaScript framework based on react 18: Hydrogen with the ability to also deploy on their new hosting solution Oxygen.

The sentry-javascript SDK already has support for @sentry/react, in this discussion I'd like to gather thoughts on how best to support Hyrdogen projects with existing functionality, and anything which might be missing. Also considering if any specifics for monitoring applications hosted on the Oxygen platform.

What to support?

• Errors
• Performance & Tracing
  • ensure quality transaction naming
  • better / contextual spans from the framework
  • transaction name should be set automatically
• Uploading Source Maps
• Release Health (auto-session tracking)
• Attachments
• User Feedback

Solution ideas:

• using @sentry/react and @sentry/tracing as is
• adding a "wrapper" around the react integration and including Hyrdrogen specifics there
• using the new Shopify CLI
  • "to scaffold out the basics"
• any need somehow hook into Hyrdogen and/or Oxygen to ensure capturing all data needed for errors, performance, and session data

Ideally there would be a seamless developer experience for all Sentry products and features whether working locally, self hosting, or running on Oxygen.

https://twitter.com/zeeg/status/1540192482066960384

[blittle]

Hi @smeubank, my initial impression is that you could hook into logging with the logging configuration:

https://shopify.dev/custom-storefronts/hydrogen/framework/hydrogen-config#logger

[frandiox]

Hi @smeubank @AbhiPrasad , we are working on an RFC for Hydrogen plugins and would like to understand better what you need.

I exchanged some messages with @AbhiPrasad some time ago on Discord and I think you could use these hooks:

• Modify logger.error to asynchronously make requests to Sentry
• Access to a hook before each request is handled by Hydrogen where you can add metadata about performance, etc. This could be added in some sort of "context object" that you can access later in-app as well, or in logger.error. Say, you can do context.myData = {url: request.url, otherData: {}}, and then call Hydrogen's useRequestContext('sentry') to access that context.

What else would you need? For example, do you send performance metric on "request ended" when there are no errors?
For errors in the browser, how do you normally handle that in a React app?

Also, about Uploading Source Maps: we intend to have "build hooks" where you could do something with the sourcemaps. However, we do not have any kind of hook for deployment since this is out of Hydrogen's scope. I assume the perfect scenario would be uploading sourcemaps when a new deployment is created in Oxygen/3p-platform, right?
Do you think there's anything we can do at the Hydrogen level to make things easier for you? We already generate sourcemaps for client and server builds but of course we can't link it to a deployment without extra help from platforms.

[AbhiPrasad]

Hey @frandiox, thanks for the help!

The hooks you mentioned are a great start for us. Typically the easier it is to forward exceptions the better.

For performance monitoring, we track require hooks onto the start and end of requests, which allows us to generate timing data around request length. In addition, any request metadata we can gather would be awesome, as we would just surface those directly to users. We track requests that both error and do not!

For errors in the browser, how do you normally handle that in a React app?

Normally we hook into the browser's global error handlers to catch unhandled global exceptions. We also allow explicit usage of the SDK through Sentry.captureException calls to capture user handled errors (like one's from a try catch block).

We also have a React error boundary for component errors.

Also, about Uploading Source Maps: we intend to have "build hooks" where you could do something with the sourcemaps

For Sentry, we just require a build step where we can grab the generated sourcemaps and automatically upload sourcemaps. In addition, we would also be creating a concept of a "release" which allows users to relate specific sourcemaps to specific released assets. If y'all are using Webpack, we would be leveraging our Webpack plugin, otherwise we would use our CLI tool to do this in the build hook.

Want a full idea of what this involves? We recently built out an SDK for Remix.run: #4894. You can see the PRs for client-side instrumentation, server-side instrumentation and support for sourcemaps as the very top items.

[frandiox]

For performance monitoring, we track require hooks onto the start and end of requests, which allows us to generate timing data around request length. In addition, any request metadata we can gather would be awesome, as we would just surface those directly to users. We track requests that both error and do not!

Right, we will support something like: request.on('end', () => waitUntil(fetch('...sentry', {body:{...}))).

We also have a React error boundary for component errors

Would there be any benefit to using the React ErrorBoundary vs raw Sentry.init in the browser? I saw there's the dialog feedback but I'm not sure if that's only possible with the ErrorBoundary or it's also available without it.

If y'all are using Webpack, we would be leveraging our Webpack plugin, otherwise we would use our CLI tool to do this in the build hook.

We are using Vite, which is based on Rollup. I think it should be possible to use the generateBundle hook or similar to send sourcemaps to Sentry, but I'm not sure how it would be connected to a deployment/release, unless it's done manually.

[AbhiPrasad]

Sweet, the request event emitter should serve our needs perfectly then.

Would there be any benefit to using the React ErrorBoundary vs raw Sentry.init in the browser

We get the React component stacktrace here, which helps debug the state of the component tree. As of React 17, the error boundary generates a more detailed componentStack: facebook/react#18561.

See: #3532

We are using Vite, which is based on Rollup

Yeah this is fine, we can just integrate with rollup/vite. We normally associate a release to a git commit sha, unless a user has a specific versioning scheme they want to use.

Appreciate all the help!