How is my JavaScript Doing?

Hi, my name is Neil Manvar, and I am a Solutions Engineering Manager at Sentry. Today, I'm going to be talking about how we can monitor our JS applications to figure out how they're behaving in the deployed environments and act on that information and go from there.

First, JavaScript is complicated, right? Since it runs in the browser, it's obfuscated, and when something goes wrong, whether it's an error or a slowdown, we don't always have the information that we need. At the same time, we're putting more and more and more of these applications out there, and we're trying to iterate on them faster and faster because that's how business is done, through the application layer now, and that's where more and more of the logic is going to live. And we are going to be iterating on this logic continuously.

Applications are growing more complex as well. It's not just back-ends and microservices, but there's more happening in the front end, there's more heavy lifting happening, and we're even doing things like micro front-ends to break these things out. And when things go wrong, it's a problem for everyone. Developers are being taken away from the things that they need to do, work on new features, and then fighting this fire. Customers are potentially going to customer, and metrics are being affected as well, right? For off-steam, it's the mean times for detection and remediation. Developers want to focus on the quality of the code, and the efficiency at which they can put it out. And the product team is looking at all of this in a big picture. Where revenue is affected, they want to get out all the new features at the appropriate time, and when velocity is compromised. So that's an issue.

So what can we do about it in the context of JavaScript applications? We have all the other monitoring regarding our infrastructure, but application stuff, especially when it's running on the client side, is very lacking. That's where Sentry's going to come in. It's going to tell you when your JS app is broken, when it's slow, and exactly why that is happening, and all of the relevant data and information regarding that. I'm going to take you through two journeys, errors and performance, and we'll go ahead and debug these things.

But first, how does Sentry work? You integrate our SDK. It's super straightforward. So for JavaScript, you can do CDN include, or Yarn add, or NPM install, and then Sentry.init. And then for tracing or performance, we want to enable the browser tracing piece and the appropriate sample rate. And the last piece is that we also want to enable release health, which is going to be enabled by default. But you would do auto session tracking truth to explicitly enable it.

So I already have this set up in my app, which I'll show you shortly, but the configuration here is such, and I'm also uploading source maps to Sentry. So now let me just go cause an error. So here, let's check out. Looks like something went wrong. And if I wasn't using Sentry, I may or may not even have this information. And you can see it's obfuscated out to have to reproduce and debug and go from there. But since I am using Sentry, what's going to happen? And you can see this just came in. I'm automatically notified something is broken. And here is all of the appropriate information.

So what I'm looking at here is the Sentry issue and this will tell me the who, what, when, where, why of the error. Sentry will automatically de-obfuscate these errors and aggregate accordingly. So let's take a look. Looks like we got a 500 that happened 70,000 times affecting 33K users. It's been flaring up over the last 30 days. Looks like it's happening on these two browsers. Affecting these customers and production on this release. So I can understand the aggregate impact of this error and the data from there and I can see the event specific data right within here. All the attributes, most notably the stack trace.

So what you would have seen in the browser looked a little bit something like this. Sentry de-obfuscated it and then showed you the relevant frames and the context lines so we can see exactly what went wrong in the code. Looks like we didn't get a 200 from the back end, so an error was thrown. Then it looks like the customer was adding a bunch of things to the cart, clicked the checkout button, our back end returned with a 500 which bubbled up to window.onerror, and all the other information the SDK deems useful, they'll attach and you can custom attach as well. The point being is now I know the who, what, when, where and why right when it happened, I didn't have to go querying around or asking around and we don't just stop there. We'll even show you the commit that caused the error.

So here, what this says is this commit right over here written by Will caused this error. So therefore, Will should be signed this issue and he can fight this fire within five minutes rather than me having to understand this code, iterate on it, and then, you know, fix it and then put it out, which would take hours or days.

So that's it for errors. We want to get it to the right people get all the details and get it so that you can fix it. And you're in and out of here.

The next thing that I want to go over is performance. So if I go ahead and take a look right over here, same type of application, what's going to be different here is that there's a slowdown as you saw. Let me just do a little bit of tab cleanup. One more time. So when I click loading, when I go to the page, it takes a while to load the result. Is it a problem on the front end? Is it a problem on the back end? I don't know, but let's go ahead and figure it out.

The other thing is when I click checkout, it looks like it's broken as well. And there's a problem. So let me just go straight into sentry. Go into performance. We'll go ahead and look at our front end project. We're also pulling in the web vital information. We can see the largest. Contemporary paint is pretty bad over here, but let me pull up the tool store here. Look at one of these and see exactly what's happening.

So it looks like 81% of the time is spent on the HTTP request. We can see when the first content full paint is loaded and all the other information we would attach to an event. And I can also then trace this to the back end if I want to view that data set if I'm using sentry there as well. But now I know exactly where the slowdown is. Is it in react land? Is it in browser land? Is it in the HTTP request? And one more use case here is I want to view all the transactions. So let's look at checkout and I can see the related issues right here. This is the aggregate view. But in the interest of time, I'm just going to dive in and I can see that there was an error associated with this transaction. So on the right-hand side, we see what's broken. On the left-hand side, we see what's slow.

And as a developer, I have all the information I would need to act on this and might not even have to reproduce, so I can fix it. So go ahead integrate your sentry into your application. You're going to get this insight.

And we'll even view this stuff from a release perspective. So for example, this release went out in the wild. I can see the crash recessions, all the appropriate adoption rates and such, and then drill down on this accordingly to find any of the issues and transactions that might have to do with any of the experiences that might have been poor.

You can also query this data set. We have Discover, and you can dashboard any of those queries as well. Long story short, Sentry is what's going to tell developers that their application is broken, it's slow, give them all the details regarding it so that they can act on it and focus on building out new features.

The last thing that I want to show you all is that we're offering three free months of Sentry. Go ahead, use this code sentry.io. Thank you all for your time. I know that this was fast, but wanted to get through all the technical material. I appreciate you.