DEV Community: Christopher Heher

Why Debugging JavaScript Sucks — And What You Can Do About It

Christopher Heher — Tue, 29 Jun 2021 18:46:37 +0000

What makes JavaScript great is also what makes it frustrating to debug. Its asynchronous nature makes it easy to manipulate the DOM in response to user events, but it also makes it difficult to locate problems. And JavaScript’s ubiquity has resulted in a variety of runtimes (e.g. Chromium’s V8, Safari’s JavaScriptCore, and Firefox’s SpiderMonkey) but having so many platforms can cause dizzying idiosyncracies — all of which need to be supported equally.

This makes pinning down the root cause of your JavaScript errors difficult. Is it a memory leak? Browser-specific bug? Or maybe you referenced the wrong value of this? And while there are options to debug your JavaScript, none of them are particularly pleasant:

Reproducing the issue is the equivalent of cooking a poorly received dinner again just to taste what went wrong. And it’s borderline impossible to reproduce the exact conditions of runtime environments, hardware, and network inconsistencies.

While console.log is great if you’re debugging locally, it’s not really helpful if you can’t reproduce it — or if you want to debug in production. That’s because logging merely identifies where in the codebase you are — but not what the problem is.

If you have managed to successfully reproduce a bug, in-browser debugging tools are the next step, but if you don’t have source maps available in production, good luck finding the root cause as you squint at minified JavaScript and opaque error codes.

It’s Ok To Be Lazy

Let’s be honest: you didn’t get this far by working hard. You did it by figuring out which tools can do the hard work for you. And Sentry’s suite of monitoring tools seamlessly hooks into your runtime environment to do the heavy lifting of debugging for you:

Sentry for JavaScript gives you complete context in the form of full stack traces, support for source maps that unminify your code, and direct integration with your source code management tool to help you identify the commit that broke your code.

Suspect commits show you the commit that introduced the error.

Our Issue Details page gives you the device, OS, browser of your user to give you full visibility into what led up to your JavaScript incident. And if you are using console.log to debug in production, we can capture breadcrumbs to create the trail of events that happened prior to an issue — then use our rich, structured data to see beyond what any log can give you.

And with Discover, our intuitive query builder, you can debug with pre-built searches that filter your JavaScript events, unique errors, errors by URL, and client. Check out Discover’s debugging superpowers — and how we used it to root out our own 404 errors.

Brian Kernighan — the inventor of Unix — said the most effective debugging tool is careful thought. Well, Kernighan didn’t have to didn’t have to debug why a valid regular expression throws an exception on Safari — or deal with the rapid increase of JavaScript-driven web APIs. But with Sentry’s application monitoring tools, you can save your careful thought for where it belongs: your code, not your errors.

Jamstack, Next.js, Netlify, and Sentry: How The Pieces Fit

Christopher Heher — Thu, 17 Jun 2021 22:24:00 +0000

Jamstack (Javascript + APIs + Markup) is a web architecture that combines the convenience of pre-built websites with the capacity to handle custom APIs and serverless functions. By separating the frontend UI from backend databases, Jamstack allows developers to structure their application in ways that deliver dynamic content faster. Jamstack also gives you the ability to deploy your frontend directly to a CDN, which enables modular development that can leverage a huge ecosystem of third-party tools — including Sentry.

Next.js

Next.js offers everything you want in a JavaScript framework: minimal configuration, TypeScript support, smart bundling, and route prefetching.

"We manage several large customer-facing properties and Next.js gives us the flexibility to easily build static and dynamic pages without spinning up servers or sacrificing the end-user experience. With Next.js, we can see our changes locally in 100s of milliseconds and have reduced build times for our larger projects from 35 minutes to 7."

–Michael Wickett, Group Manager, Web Development, HashiCorp

And when you install our freshly-released Next.js SDK, you get the necessary context to understand how certain events can lead to errors or performance issues in your application. Our Next.js SDK automatically captures errors, breadcrumbs that show what led to an issue, and all the meta data required to fully diagnose a critical problem.

Netlify

The Netlify platform combines modern build workflows, serverless functions, and an edge network to deliver simple, secure, and scalable Jamstack applications. With Netlify’s custom testing environments, you’re able to evaluate multiple new features at the same time without needing to schedule feature previews for approval on a single test instance.

Sentry Build Plugin for Netlify

And just as Netlify hosts your Jamstack application, Sentry monitors it with our Build Plugin. Not only does our Build Plugin automatically notify you of new releases, it uploads source maps and configures suspect commits within the Sentry platform. And if you do see anything suspicious, Netlify makes it easy to instantly roll back to a previous, sturdier version of your application.

"The most noticeable for us was saving an average of three hours per week on performing deploys, setting up configurations and maintaining infrastructure. For a small web dev team, this has a huge impact."

–Primož Bevk, Senior IT Strategist at Outfit7

Discover

It’s not enough to know when a performance issue happened. You need to know who’s impacted by that issue, to what extent, and how it occurred. Discover solves these needs, as you can identify application performance issues, analyze releases, define a metric alert to get notified of similar issue — in addition to evaluating the line of code that’s causing the error.

Just as application errors are related, the tools to fix those errors should be related as well. It’s why you don’t need a bunch of disconnected tools to monitor your application; you need an integrated, intuitive approach to investigate problems. With Jamstack’s simplicity and Sentry’s visibility, you’re well on your way toward creating — and maintaining — the type of applications that your customers demand.

How to Find Root Causes (Faster)

Christopher Heher — Thu, 17 Jun 2021 21:49:27 +0000

Like a bratty teenager, traditional monitoring answers your questions, but does so in a terse, unhelpful manner:

Why is my page slow?

Guess it’s the API call. It’s a 504 thing — you wouldn’t understand.

Ok, so why is the API call slow?

Ask your DB query. Gosh!

You need a better conversation with your code — one which gives you contextual clues about your application’s performance. And that’s what we’ve delivered with our new Trace View and Quick View features.

Connect your slow-loading dots with Trace View

Trace View gives you a throughline between transactions across all your projects. Now you can follow poor performance to its root cause by drilling down into the details of a single trace as well as crisscrossing between front- and back-end transactions in that trace.

For example: say you have a React single-page app, and it makes a call to a backend API in Python, which then queries the database. By using Trace View, you can see how your code progresses from the initial call to the final query — and see how related errors react to each other in context.

In the above video tutorial, see how you can use Trace View to jump between parent and child transactions and, ultimately, gain a better understanding of your endpoints.

Tl;dr your errors with Quick Trace

You don’t read logs — you scan them. So why should your application monitoring be any different? Quick Trace gives you the context you need to see details at a glance as well as get visibility into the bigger picture. Our Quick Trace minimap helps you navigate related errors and children transactions. With it, you can flit between related errors and performance issues while also being able to order metadata like device, OS, and browser.

Quick Trace shows related transactions, along with any errors that occurred in them. Now you can navigate between the events of a trace without having to go back and forth between tabs.

Developers know that there’s no such thing as an isolated issue. Many of your frontend errors will have roots in your backend infrastructure — and vice versa. With our new Trace View and Quick View, you’re able to see the problem clearly — so that you can solve it quicker.

Find the Root Cause Faster with Trace View and Quick Trace

Christopher Heher — Wed, 16 Jun 2021 19:56:48 +0000

Like a bratty teenager, traditional monitoring answers your questions, but does so in a terse, unhelpful manner:

Why is my page slow?
Guess it’s the API call. It’s a 504 thing — you wouldn’t understand.

Ok, so why is the API call slow?
Ask your DB query. Gosh!

Connect your slow-loading dots with Trace View

Tl;dr your errors with Quick Trace

Try Sentry for free today or contact us at sales@sentry.io to get started.

Measuring Success with Sentry

Christopher Heher — Tue, 18 May 2021 22:00:52 +0000

In the early days of web development, there was one way to measure code: WTFs per minute. It was a metric that could be applied across all languages, as every developer knew what WTF meant (Works That Frustrate, obviously).

Today, however, code is too intricate — and important — for clever, opaque metrics. You need objective data that communicates the quality and stability of your code — KPIs such as events accepted, transaction outcomes, and crash-free sessions.

For Measurement May, we’re building out features designed to deliver the right metrics, all so you can drive the right outcomes for your organization.

Create Your 0wn Visibility with Custom Dashboards

Understanding the state of your application starts with understanding the errors, transactions, and attachments that make up your event data. With our latest update to Dashboards, you’re able to surface critical event data as well as share that data across your organization. While we’ve equipped Dashboards with a library of prebuilt widgets — issues by region, performance over time, release quality over time — you can also build your own custom queries within your personal dashboard.

And you can enhance your visibility even more when you combine Dashboards with Discover, our query builder. Say you've built a widget that compiles top issues across all your projects:

When you open this widget in Discover, you can measure progress across multiple projects over time while also comparing additional filters — unhandled errors, URL, browser type, etc. This way, instead of scrolling through listed queries, you’re able to provide clear visualizations to higher-level managers so you can achieve consensus over what to do next.

All Details, One View with Project Details

It’s a common plight among developers: twenty tabs open, just to figure out one problem. Your errors, transactions, and sessions shouldn’t be spread across different screens. They should be available on one screen, and at a glance. Our new Project Details page unifies a developer’s monitoring experience across all aspects of a project - health, speed, recent alerts, and releases. With it, you’re able to see project-wide KPIs for stability (crash-free sessions), velocity (number of releases), and performance (Apdex score). You can also compare this data over time so that you’re able to track incremental progress.

Know How Much Sentry You’re Using with Org Stats

For developers who manage other developers, statistics is the language you use to control spend, manage quotas, and create efficiencies. With our new Org Stats page, you now have the information you need to see which areas of your codebase demand the most resources. With it, you can track how many issues are being created — and resolved — per week for each project. Charts and tables also provide insight into per-project usage over time of your errors, transactions, and attachments. Now you can not only see which projects had a recent spike, but you can also link to the project details screen and immediately see what needs to be addressed.

Measurement May is upon us. Here’s a primer on Google’s upcoming Web Vitals update, and also join us on May 20th for a live demo on how to build custom dashboard widgets and much more.

New to Sentry? Try it for free today or contact sales@sentry.io to get started.

Measuring User Experience with Web Vitals

Christopher Heher — Fri, 07 May 2021 16:54:49 +0000

Top of search for you means top of mind for your customers. And with Google’s upcoming Page Experience update to Web Vitals taking place in a few weeks, now’s the right time to optimize your user experience. But before you can optimize your user’s experience, you need to be able to measure it. We’re kicking off Measurement May by breaking down how Google uses Web Vitals data — and how you can instrument that data with Sentry.

Web Vitals Basics

This past May, Google introduced Web Vitals, a set of three key user experience metrics:

Largest Contentful Paint (LCP) measures a page’s loading. The goal here should be a LCP within 2.5 seconds once the page starts loading.

First Input Delay (FID) measures a page’s interactivity. A solid user experience here means there’s a FID of less than 100 milliseconds.

Cumulative Layout Shift (CLS) measures a page’s visual stability. For a good user experience, CLS should be less than 0.1 seconds..

Web Vitals + Page Experience

After their upcoming Page Experience update, Google will evaluate your web pages moving forward with these four metrics:

Mobile Friendliness determines whether content is responsive to mobile devices — making sure joins and on-page components are stable for a spectrum of devices.

Safe Browsing assesses whether a site has issues with malware, phishing, and hacked content.

HTTPS evaluates whether the site’s association is secure and if the site is being served over HTTPS.

Non-Intrusive Interstitials ensures that certain content won’t be blocked for pop-up content as a user explores the page.

The Results Are In (Your Content)

It makes sense that Google’s Web Vitals will impact how your website will be ranked in search. But Google’s aim here isn’t to be some fussy stickler about how you build out your content — it’s to raise the conversation around content itself. With these new guardrails, Google is able to push down content created for its own sake, and elevate content that’s created with a user’s experience in mind.

The E-Commerce Impact

Because they’re often large (thousands of SKUs), complex (dynamic pricing and backend security measures), and dependent on search (via keywords), e-commerce services in particular will benefit from increased Web Vitals and site performance. And because each page in an e-commerce domain is indexable and searchable, every product page now represents an opportunity to generate revenue — if it has strong Web Vitals data.

Be Performant. Use Performance.

With Performance, you’re able to compare user metrics such as network speed, browser, device, and region against Web Vitals thresholds. This helps you see those specific transactions which are slowing your user’s experience down. You can hone in even further by building a custom query in Discover — say, adding event tags as filters to your query.

In this webinar, Sentry Product Manager Jeremy Bourque demonstrates how you can set up Sentry's performance monitoring to surface poor-performing pages through Web Vitals.

While gathering Web Vitals data is important, you still need visibility of that data across all your projects. With our new Quick Trace feature, you’re able to easily navigate between errors and performance issues via a mini-map. And our Trace View gives you a waterfall visualization across all your transaction times, so you can see what project is responsible for the most problems. With it, you’re able to see dependencies of any given trace in a single view as well as what projects they live in.

For some, Web Vitals represents an inconvenient data hoop that their code has to jump through. For others — and hopefully, you — Web Vitals is an opportunity to distinguish yourself in the marketplace, as less than 15% of sites are optimized well enough to pass a Core Web Vitals assessment. It’s the metric that can be the difference between your customer buying — or bouncing.

Measurement May is just getting started. In an upcoming live workshop, a Sentry Solutions Engineer will show you how you can analyze event data to measure the health of your application.

Get started with Performance and drop us a line at our forum or on Discord. And if you’re new to Sentry, you can try it for free today or write to sales@sentry.io to get started.

Issue Detail Performance Improvements

Christopher Heher — Fri, 09 Apr 2021 21:56:32 +0000

One of Sentry’s most-trafficked pages is our issue details page, as it helps our customers understand the root cause of an error. For those of you who are new to Sentry, we define an issue as a group of similar events. And to render these issue details, we need to fetch a significant amount of data from these events — counts, charts, and other metadata.

There are two components to this page: latest event, and summary statistics. And the problem we faced was that the page was loading the latest event only after loading the summary statistics, creating response times of more than a second.

We had no idea what — or why — this was happening. First, we worked toward solving the what. Using Performance, we noticed that the latest event loaded only after the summary statistics loaded; that is, we could see the second request could only start after the first request had finished.

Next, the why: looking into the issue page’s React component tree, we noticed that the latest event component was a child of the summary component.

Although we were fetching the data for the latest event in its component, because this component could only begin rendering after its parent has fully rendered (which in turn is blocked by the parent request), the two requests were not parallelized.

Our fix was to begin loading data from both endpoints higher in the component tree, allowing us to parallelize both requests. Then we passed the result down so each component can render as soon as its data became available.

After the fix, the issue page’s P75 response time dropped by about 1 second:

You can’t fix what you can’t see. And because Performance gave us the visibility into the two requests that needed to be parallelized (but weren’t), we were able to find the quickest path to a solution — and a faster page for our customers.

Using Feature Flags in Sentry

Christopher Heher — Fri, 09 Apr 2021 16:42:30 +0000

From testing in production to running A/B tests, feature flags have a range of uses. At Sentry, one way we use feature flags is to safely allow beta access to new features for some of our “Early Adopter” customers.

Because you can set multiple combinations of feature flags, every user is likely to have a different experience. While that's great for finding answers and iterating on product, it can be increasingly difficult to determine where certain errors and performance issues are coming from. Are my users having trouble because they are part of experiment A or experiment B — or some combination of the two?

Tagging feature flags

Thankfully, Sentry can answer these questions using tags. Tags are key/value string pairs that you can bind to your events and transactions.

You'll want to set a new tag for each feature flag you want to surface in Sentry. Here is some code in one of my apps that passes in the show_widget feature flag for a given user:

Sentry.init({
    dsn: '__DSN__',
    // ...
});

Sentry.setTag("show_widget", user.showWidget);

After you start passing in feature flag data, you'll begin seeing your new tags in Sentry. In the example below, you can see that this issue primarily impacts those users who are seeing our new widget feature.

Using Discover + Tags

Once you have your tags set up, you can use Discover to see which combination of feature flags are causing errors or performance issues.
In Sentry, navigate to Discover and click Build A New Query. Then, add columns for each of the feature flags/experiments in question.

Once you've done that, you'll be able to see which flags are causing problems for your users.

It looks as if errors were primarily impacting the intersection of users who have both the show widget feature enabled and variation 2 of our new checkout experiment. From here, we’re able to use Discover to drill down exactly what issue is causing problems. Then we can decide which feature flag needs to be disabled until we have had the chance to fix the problem. Crisis averted.

Feature flags allow you to control access for a variety of release scenarios: new features for early adopters, organizations with special plans, or even incremental releases. By safely activating — or deactivating — certain features, flags can close your feedback loop, while allowing you to address an issue without the pressure and stress of a live incident.

Want to learn more about what we’ve done with feature flags? Here’s our latest Dogfooding Chronicles post. If you’re new to Sentry, you can try it for free today.