I want to talk a bit about what it was like to develop this product, the technical challenges we faced, and the way we’ve used the increased visibility into our own users’ browsers to better understand how our code is working.
The first step in building a system that makes it easy to see the JS errors and AJAX happening in user browsers was figuring out how to collect the data. We have some experience writing instrumentation at New Relic so we knew decoration was the key. Instrumentation, whether it’s for Ruby, Java, .NET, or Node, nearly always follows the Decorator Pattern. This is one of those classic “Gang of Four” software design patterns. The goal of the decorator is to add additional functionality to an object dynamically. Pretty much every language has a mechanism for doing this, whether it’s swizzling, alias_method_chaining, function wrapping, or byte code manipulation.
Say you have a function that does something. It might look like this:
You may decide to decorate this function (and other functions) with some additional behavior that logs how long the function took to run. That might look like this:
Chase Douglas and Nick Niemeir developed a system for decorating the interesting APIs in the browser, creating a low impact mechanism for installing listeners on events, setTimeouts, and AJAX calls, and providing a way to ship useful information from a huge variety of browsers to your eyes. Our continuous integration setup runs our test suite against the 20 most popular desktop and mobile browsers (representing nearly all internet traffic) to help ensure compatibility and root out obscure browser bugs.
Object #<Object> has no method ‘object’
On the Browser App overview page we graph the percentage of “Page views with JS Errors.”
If you dig deeper, into the JS errors tab, you’ll find graphs that show you the number of page loads that were effected by a specific JS error.
This helps minimize the noise for errors thrown in a tight loop by one browser to help you quickly identify the problems that many users are experiencing (and the browsers they’re experiencing them in).
And for when you’re diving deep into a problem we also provide complete details from individual error occurrences, including error message, stack trace, browser version, user agent string, url, and controller action. No we don’t just use
We’re also providing visibility into the AJAX requests hitting your site. For the non-technical crowd, AJAX is a way for a web page to request more data from the server without completely loading a new web page. It’s everywhere. Single page web apps do it and it’s increasingly rare to find a traditional web app that doesn’t have a significant AJAX component.
However, while many companies (including New Relic) have offered “Real User Monitoring (RUM)” for years it’s almost unheard of for developers to have visibility into how their apps’ AJAX requests are performing.
Fortunately, with today’s release, it just takes the click of a button to see the response times, throughput, HTTP status codes, and data transfer of all your AJAX requests recorded from the end users’ point of view.
We’ve found having increased visibility into AJAX to be extremely helpful for quantifying the effect that performance problems have on the end user experience. If you’ve ever waited for a slow chart to load on rpm.newrelic.com you know what I’m talking about. Now we can see how long our customers are waiting for their charts to load and focus on improving that experience.
We hope you like what you find and we look forward to your feedback.