New Honeycomb Whitepaper on Frontend ObservabilityBy Charity Majors | Last modified on May 23, 2022
Big news: I can finally stop pointing anyone who asks about Honeycomb’s story for frontend observability to Emily’s blog post from 2017 on “Instrumenting Page Loads with Honeycomb.” (It was a great post, don’t get me wrong, but I don’t think any of us knew it would bear such weight for so long.)
I am ecstatic to announce that we have released a new whitepaper called “Getting Started With Honeycomb Client-Side Instrumentation for Browser Applications,” written by Danyel Fisher, George Miranda, Emily Nakashima, and Michael Sickles. This is a momentous occasion, long anticipated, and must be celebrated with the appropriate triumph!
More importantly, this is a big first step towards us finally starting to pay the same fond attention to frontend developers and their needs as we have for more traditional backend-type workloads.
There are some remarkable analogies between the way backend developers and operations engineers had been stuck in the dark ages of metrics-based monitoring tools until observability came along, and the way frontend developers and designers are still stuck in the dark ages of metrics-based Real User Monitoring (RUM) tooling. Both monitoring and RUM tools were typically built on top of metrics, with loads of pre-aggregation, pre-defined schemas and dashboards. RUM is notorious for giving you lists of outliers to debug—top 5 unique crashes, top 10 slowest queries—which is a perfectly reasonable place to start, but isn’t going to do you much good once you need to understand the behavior being reported by a user who is not on any of those lists or trying to figure out why queries that haven’t been updated in years are suddenly returning 10 times more slowly.
Frontend engineers need the same underlying functionality to understand their complex systems as backend engineers do: tooling built to handle high-cardinality, high-dimensionality data, with an explorable, open-ended interface designed to reward curiosity instead of frustrating it or punishing you.
After all, the web is the O.G. distributed system. Browsers are the original high-cardinality, high-dimensionality data set. Frontend engineers are software engineers too, and their domain is every bit as challenging and difficult. So give them real engineering tools, dammit.
And that’s not all. We have already learned how awkward, tedious, and expensive it is to rack up handfuls of so-called “observability” tools, a different tool for every data type and/or use case, expecting an engineer to sit in the middle of them and make sense of the entire mess. Here’s your metrics tool, your monitoring tool, your logging tools, your tracing tools; here’s the tool used by SREs, the tool used by backend SWEs, the tool used by frontend SWEs; and here’s poor you sitting in the middle, copy-pasting unique IDs from one to the next, squinting at the shape of the curves on multiple tools to pattern-match roughly for timestamps.
Nobody wins in a world of too many shitty tools, all customized for narrow use cases. We all win when everyone can use the same data to get their needs met, because the tooling is flexible and high-precision enough to let you slice and dice, derive and graph, aggregate and group and calculate from a single, raw source of truth.
If you instrument your code correctly, you should be able to follow a trace alllll the way from a click of the UI to the db query it generates, and back again. Break down the barrier between frontend and backend worlds, a barrier which should never have existed. Tools create silos. Break down yours.
Honeycomb may not yet be able to go head to head with the state of the art frontend tooling for customized instrumentation and ease of use, but we’re coming. This paper is a big first step in that direction and I recommend downloading and reading if you haven’t already. ☺️
"Dear Miss O11y, I’ve been following Honeycomb for a long time, and I understand where the insights from observability fit in. But larger orgs haven’t...
In the same way as the business is likely ok with you writing developer-based tests (unit, automation, integration), instrumentation is the same. The conversation we...