Observability Matters: This Time for Frontend

So, hi, everyone. My name is Yash Varma. I'm a software engineer and a computer researcher. I usually talk about all things observability, from backend performance to databases, and this time, frontend. I call myself an open telemetry enthusiast, because if you are not familiar with what is open telemetry, in short, it's a project under CNCF that aims at creating a vendor-neutral observability framework for logs, metrics, traces, and many signals we'll be adding in the future. If you are interested, go and check it out. More on this later on the talk. When I'm not involved in tech, I usually enjoy cooking and trekking. This is my pretty dog. His name is Ty, and yes, I am a dog lover. So, let's get into the talk.

So, today's talk is titled as Observability Matters, this time for frontend. Excited? So, this will be our agenda for today. It will be pretty straightforward. First, we will start with the evolution of ZEP over the last few decades. Then we'll move into the understanding what and why around observability. Then we'll see the current state of front-end monitoring tools and its challenges. Then the core essence. What exactly is front-end observability, and why it is important for us? Lastly, we'll see front-end observability direction. So let's hop in. Hop in.

So, it's story time, right? Let's start from a good story of how I get into the front-end, and how it's related to my front-end observabilities. So, let's get started.

I see this story, and it's title is Beyond Assumptions, A Shift in My Perspective. So, it was 2019. I was in my university. I was exploring the vast world of technology for the first time. And like many of the students, I relied on blog posts and surrounding tech communities that how should I begin my tech journey. However, the advice was almost the same from everywhere. Get started with HTML, CSS, JavaScript, and then learn the basics of React because, you know, front-end is easy, they said, and back-end is where the prestige was.

So, you know, I learned that thing. And I accepted that thing in my initial journey. Sooner, I got a work opportunity that is going to challenge all of my pre-assumptions thing. And the best part? I was completely unaware of that. What's there for me in the future?

So, this was an internship at one of the country's biggest food delivery startup. My role was into the front-end team, and I was responsible for managing and building interfaces that millions of users would be using into their daily basis. But in my spare time, I always tried to engage with the back-end developers. Because I needed to learn from them how they worked. I thought back-end was the ultimate world for me in the development journey, so why not to be a part of it in some other way? Because they talk about scaling, distributed systems, and performance. You see it. Things that were far beyond my scope at that time. Additionally, this was the first time I saw that how these people are efficiently able to manage and keep a watch on their entire system.

So sooner, the reality hit me hard. Just after a few months into my internship, I realized that front-end development was not that easy, which I expected it to be. Every small change in the UI, every tweak in a JavaScript function could trigger a cascade of user feedbacks. One simple layout or adjustment can lead to the flood of angry support tickets. Sometimes even users took to social media to voice their frustration when things didn't work out right for them. And all of that was happening in real-time, with hundreds and thousands of customers placing orders, you know, like every day. With time, it became clear that front-end is the first point of contact between the product and its users. It's where businesses meet with their users, and this is where the perception of speed, reliability, quality is formed, and most importantly, it's where the revenue is generated. So we as front-end developers have a unique challenge because unlike back-end, unlike front-end developers, our mistakes are visible to everyone immediately.

And the funny part, sometimes we often have to deal with the mistakes that are unknowingly done by the users. Any guesses? It's our, you know, like unknown friends, the browser extension, if you know, you know.

So let's step back for a moment and consider that how the web has evolved over times. In the earlier days, web was pretty much simple in many ways. A simple web page involved HTML2 structure content, some basic styling, and a little bit of JavaScript for interaction. It was easy to understand and things felt manageable. But that's not the web we know today.

Today's web is a different world in itself. One that has grown into a complex ecosystem. We no longer just have standing pages and adding occasional JavaScript. Modern web is about building an entire application that runs in the browser for millions of users in a complete sidebar. Alongside the application code, we often have to work with various framework and libraries like React, Vue, Angular that helps us to manage the state and dynamic user interfaces. We often rely on APIs, microservices, a serverless function to provide the data from our backend. And what's the result? A user interface that's more interactive, but as far as complicated under the hood.

This evolution has created, I think, a paradox because the web has become a more beautiful place, a more capable and more engaging than ever before. But this beauty comes with a greater complexity. The minimalist, easy to manage web is gone and replaced by a complex frontend architecture that demands a constant vigilance and maintenance.

So with this brings to the heart of today's discussion, observability. But what exactly does it mean? So you know, like, let's see how control theory defines it. Observability is something like observability is about being able to understand what's happening inside the system based on its internal or based on its output. Okay, so this is what control theory says. But if you're not familiar, what is control theory? Or if it's the first time you are writing the word observability, don't worry, it's completely okay. Here's a simple way I explained it to my younger siblings. That imagine, you decided to play a memory or a GPU intensive game on an old PC or perhaps try to do something else like video editing or even watching an 8k video in that. So as soon as you hit start, you will notice that your PC for a fan suddenly spins at a very fast rate, producing a loud noise. Sometime the system might even crash and satch down in an unexpected way. So when the fan speeds up and you hear the noise, you know that something unusual is happening inside your PC. This scenario perfectly illustrates observability at some level because you know like, how you can understand the internal state of your system like a high GPU usage or you know like by observing its output, such as fan noise or overheating, and sometimes system crashes. So we can say that it's the ability to say, given this behavior, what is happening inside. So but here is where things get tricky for front end developers.

Like back end, their observability is often a built-in part of the workflow. We front end developers are not used to use the word observability in the first place. For us, it looks like something like this, and we often try to stitch together multiple sources like solutions to try to achieve a semblance of visibility into what's going on into our system. We often use tools like error monitoring, alerts, session replays, metrics, sentient monitoring, serial monitoring, logs, and everything in between you can imagine.

So you know, this is okay. But where each tool gives a part of a picture but never the whole story, you have to see. For example, when a user reports a bug, it's really a straightforward process. The customer team will often escalate the issue saying that something like, this feature is not working for this group of users. But remember, recognizing the problem isn't always easy. So we ask for a screenshot or console log and more details trying to recreate the issue in our own environment. Sometimes it's a tedious process full of back and forth and that can quickly frustrate even the most passionate of developers, if they have to do it on a regular basis.

So if you compare it to the back-end world, it's like comparing a fragmented puzzle with a complete picture. Some engineers have access to the rich logs, collated data, distributed traces, metrics, logs, event alerts, you name it, and all of them coming together in a one single stream. They can trace certain user behavior whenever an alert is triggered, pinpointing where the request slowed down or even failed. Eventually they have a full few tools to see in it all, making it easy to diagnose and fix them. But for front end developers, it looks like, looking at the back end folks, it looks like staring at a paradise from a fence. The back end side seems to have, you know like everything, a streamlined process, clear metrics, the ability to drill down deeper into the tiniest of details. But for us, it's like assembling a car while driving on the highway. And this is where I believe we front end developers have lagged behind in getting an in-to-in visibility into our system in some sense. But the grass looks greener on the other side, I would say.

So moving on, what tools would we use as front end developers? So let's talk about the two most common things. First one is synthetic monitoring. It's like a control experiment. You can set up tests that stimulate user interaction, clicking buttons, loading pages and so on. But here's the real catch. This is by definition synthetic and usually works around the known knowns. It cannot replicate the messy reality of the regional user behavior. Bots cannot mimic the unpredictability of users of how they use own browsers, have poor network connections or interact with their app in hundreds of different ways.

I believe that when it comes to understanding the word production, we front end developers understand production as the user device. There are millions, so we deal with the millions of production, I believe. So cheer away. This brings us to the next tool, the real user monitoring. It tracks the actual user interaction on your site, giving you a window into what real users are experiencing. It collects data on page load time, network performance, device type and more. It helps you to understand, for example, whether users in a specific region are experiencing slow page load time or if a particular device is causing the error.

So however, we should understand that RUM is usually not without its challenges. First, the RUM gives us a very high overview, but often doesn't provide us the deeper context that is needed to understand the root cause of the issue. We often struggle between RUM-load, log aggregators, edit-tracking tools and just to get a piece of, just to get, just to piece together what's going on. Adding user-specific context can quickly become time consuming and it can also escalate the cost. The second reason is the RUM-agents. These can sometimes cause conflicts with the scripts in your own site. Ironically, these agents can become a source of bunt themselves, especially when they don't play well with third-party services or custom user scripts. In some cases, they even become a reason for the next user complaint. Lastly, we have a tool, RUM tools often struggle when the session hours last for too long. Like when a user leaves a tab open for hours, the data becomes harder to manage and interpret. Leading to a gap in understanding of what the user is actually experiencing. It's great at giving an overview, but less effective when you need to dig down deeper into a user-specific journey. So, the question is, isn't about whether we have a good tool. The real challenge is about storytelling. Our present monitoring tools do a good job of telling us what is happening, but they often fall short in explaining why it is happening, why a specific user experiences a slow downtime, and why some of the users don't.

So, this gap in understanding means that we need a lot of time in hunting, we spend a lot of time in hunting down the real cause of the problem, rather than solving the problem quickly. I would say this is where front-end observability really shines, because it works around the principle that context is everything. And, using this context to not just monitor, but to understand how your application performance for different users and in different situations.

So, with good context, we can say that we can easily connect the dots to gain a clear view of our front-end and just right time. For instance, we can say that we can now monitor the web vitals, but not analyze them, but to drill down deeper into the insight. Like this one, this is an example where we can see the core web vitals, also the FCP, NCP, and different things. And also we can drill down deeper into that data to a specific user session. This is a learning thing that we can drill down deeper into like sessions and events to identify when the user encounters an error, what type of error it is, and whether it's a bad response or a content loading issue or a specific front-end code problem. And pinpoint which part of the code caused it. This level of details helps us to understand the entire user journey.

Now we have specific session data like front-end observability unlocks many such insights, including the exact correlation with the front-end activity and the back-end traces. However, in this example, we can see that with front-end observability, we can drill down deeper into a specific user, see what the journey looks like and what is the journey the user has gone through, the GET requests, the IRR posts, how many requests have been there. And also we can see the errors, if they have a slower downtime in some cases, like what is causing this error. So we can also see that session-specific data. And we can also see an end-to-end trace correlation data from a front-end to a back-end. So front-end observability unlocks many such insights, including the ability to correlate the front-end activities with our back-end traces. This allows back-end developers to see how their changes can impact the real users on the front-end. This feature is incredibly valuable in enhancing the developer experience also, not just for the front-end or the back-end, but for the entire engineering team. With this approach, we can now better understand, identify, debug and access the impact of the issue on our applications. Now we have that. This is what front-end observability aims to achieve. A world where we move from reactive debugging to proactive optimization.

So now, why am I here today talking about observability? It's because it's time for us to take the next step as a front-end developer. The web has changed and our role has changed with it. We cannot always rely on the traditional way of monitoring and debugging anymore. If there are some key takeaways from this talk, that would definitely be around, like, it's time to rethink observability, not just as a toolset, but as a mindset. Because it's not about just having a better tooling. It's about adopting observability as a culture within an organization. It's about breaking down the silos between the front-end, the back-end, or the entire engineering team to understand our product, our users, in a more effective way. So when front-end developers understand what's happening in the back-end and vice versa, we can better understand the entire user experience, how the user is behaving, what does the user want. So, like, observability becomes a shared responsibility that makes our entire system more resilient. So you know, that's it. So thank you for joining my session today. I hope you enjoyed it and learned something from that. And if you're really excited about front-end observability, I would soon, you know, make some more content on that. So until then, thank you for joining me. See you soon.