Presentation: Observable JS Apps

Track: JavaScript and Beyond: The Future of the Frontend

Location: Windsor, 5th flr.

Duration: 4:10pm - 5:00pm

Day of week: Tuesday

Level: Intermediate

Share this on:

What You’ll Learn

  1. Listen to what are some of the instrumentation best practices today, what data to collect and why.
  2. Hear about back-end observability practices that can help understand what is going on in an application.
  3. Find out what are some of the tooling changes that take place on the back-end and how to apply the principles to the front-end.

Abstract

Observability isn't just for backends. Client-side javascript applications are the original distributed systems software: real-time, heavily cached, single-paged, asynchronous, multi-domain, with polyglot persistence layers and cascading dependencies and always running massive amounts of JS. So what can we borrow from backend observability practices, in order to better understand our users and how they really experience our applications?  How can we get our finger on the pulse of modern JS apps running in production?

Observability means instrumenting your code so that you can ask any question, whether you anticipated it or not, and understand the internal state of your systems just by observing its outputs. Emily will talk about an event-driven approach to client-side observability for the most complicated parts of Honeycomb's customer-facing React app: the query builder. She will cover instrumentation best practices, what data to collect and why (spoiler alert: high cardinality is queen), and how they use that data to slice and dice and zoom in on some of the strangest unknown-unknowns for real customers. Code examples will be primarily in React or vanilla JS, but takeaways will apply to other popular frameworks. Examples will be in Honeycomb, but context is relevant to distributed tracing and other distsys debugging techniques.

Question: 

Tell me a bit about managing the product team at Honeycomb.

Answer: 

We are a super small startup, we're scaling up quickly. The interesting thing that my team is tasked with is creating new ways to visualize and understand complex distributed systems. The tool is in a space between log aggregator, metrics, tracing — the intersection of all those kinds of tools. The most interesting thing that we do is to come up with new ways to take complex data and make it clear to engineers.

Question: 

How do you instrument the front-end to be able to trace and log and do all the things that you just talked about?

Answer: 

I've always been a little bit of an ops groupie. Strangely enough I think a lot of front-end developers to advance in their careers move to back - end roles. But I always have found that I was more excited about the infrastructure side of things, understanding networks and systems architectures, and that has been super helpful in trying to understand front-end code in production. The tools that I have applied to that problem tend to come more from what I've learned from ops folks, and the ways that they are thinking about understanding their systems. And that's definitely what this talk is about, thinking about how to take these event driven tools and use them on the front end. The high cardinality problems that are occasionally blockers on the back-end are happening every day and all the time in browsers — it's always that long tail bug it only happens in this one browser or to this one customer.

Question: 

How you you describe the persona and level of the target audience?

Answer: 

A senior full-stack or frontend engineer who is up to date on the latest javascript frameworks, APIs, and practices, but may not have advanced ops/infra/monitoring knowledge.

Question: 

Can you give me an example of one of the techniques you talk about?

Answer: 

Probably the most interesting thing that I'll be sharing is about how to think about instrumenting single page apps. The community has understood instrumenting page loads really well for a long time. This talk is about starting to pull apart all the things your SPA can do and figuring out how to map your events to the common paradigms in SPA. It may be the most boring but most actionable thing I'll get into. There are analogs to thinking about how data flows through back-end systems.

Question: 

Can you give me an example of a back-end concept that you can apply to the front-end?

Answer: 

Many lessons learned from distributed tracing tools are useful on the front-end. In some ways that paradigm is more natural to front-end developers because they've been used to be looking at the network panel to do debugging for a long time. The next step is thinking about how you can take that data and aggregate it and not just use it to debug a slow performance situation that you can reproduce reliably locally. Aggregating all that data together helps you both understand the normal state and also allows you to debug complex customer facing problems in production that you can’t reproduce locally. That's a neat place where back-end and front-end tools are converging together.

Question: 

Are you talking about events that are emitted from the front or back-end code?

Answer: 

I'm primarily talking about instrumenting frontend browser code. There's some interesting work that we're looking at around instrumenting server-side rendering too, so that people can decide whether they should have a particular piece of logic running on the server or the client side. Being able to instrument those is important, but the focus of talk is primarily stuff that runs on the client.

Question: 

Has what you're talking about more affinity to React Redux style?

Answer: 

The code examples that I will show will be from our React app but it's not a super code-heavy presentation. The takeaways will apply to any AJAXy application. People using Angular, Ember or any other SPA framework will be able to take a lot of actionable ideas away from the talk. It doesn't require any particular architecture and certainly doesn't require React & Redux.

Question: 

Are you talking about emitting events, about instrumenting the requests or both?

Answer: 

It's definitely both. You want to be able to instrument request and loading, but we're also looking at rendering and even user interactions that only happen in the client and never trigger a request.

Speaker: Emily Nakashima

Engineer @Honeycomb & Co-Organizer of the AndConf Code Retreat / Unconference

Emily manages the frontend/web/product engineering team at Honeycomb.io. In the past, she's worked on javascript, web perf and monitoring at companies like Bugsnag & GitHub. In her free time she organizes an unconference called AndConf, makes many checklists, and likes to talk about disaster preparedness.

Find Emily Nakashima at

Last Year's Tracks

Monday, 5 March

Tuesday, 6 March

Wednesday, 7 March