Why Should I Care About Client-Side Logging?
Recently, the Loupe team has added JavaScript client-side logging to their ASP.NET Core Agent. It’s a feature that is pretty exciting for me personally. I have worked on JavaScript projects without any client-side logging and know it’s a pain. If I had client-side logging, I could have avoided some embarrassing phone calls and most likely spotted some errors I never even knew about in the first place.
If you are not familiar with client-side logging, this is your chance to get to know why it’s useful for JavaScript developers and how it can improve your troubleshooting experience.
What is Client-Side Logging?
By default, errors in the browser are written into the console rather than into a file. The browser console is a great resource when developing applications. But it has an inherent weakness: none of the console output is saved by default. Once the browser session ends or the user changes pages, any data is virtually gone for good.
That may not be a problem during development. You can save any console output you really need. And if you are making a primarily static site, client-side logging may not show you any data you couldn’t find with Google Analytics. But, this can be a tricky issue once an application is in production. When more people use your application in ways you never intended, there are bound to be unexpected errors. Since this data is not saved anywhere by default, many developers rely on user reports to discover these errors.
Client-side error logging is an alternative to this. It allows you to capture in-browser JavaScript errors and send them to a location where developers can easily view them. This way, no one relies on user reports and can catch errors as they happen in production.
User Reports are Not Enough
This is a possible workflow due to relying on user reports! I.E., A workflow I lived
User feedback of any kind is valuable, especially feedback that can improve the experience for others. But, there are some problems with relying on user feedback as the only way to discover JavaScript errors for your application:
-
The user may not know they have encountered an error. Most people do not have the console open while browsing the web and will not always know when an error occurs. What is unexpected behavior for your application may not register as a problem for the user at all.
-
The user can be an unreliable narrator. If someone struggles with a technical problem, they may not be in the best frame of mind to discuss the issue. They may not remember the steps they took that resulted in the error. Or worse, remember incorrectly.
-
It may be difficult to replicate an error. There are a lot of different browsers, devices, and ways to use your application. Frankly, too many variables to guarantee you can replicate the error in the first place.
-
The user is likely to stop using your application rather than call you about an error. By the time a user wants to email or call you about an error, it may have already happened to ten other users who decided to find something else instead. In a world where applications rely on free versions or trials to get people’s attention, many users can cut bait easily if something doesn’t work for them.
Relying on user feedback to discover client-side problems is very frustrating. For every user that was kind enough to call and report they were having an issue, I knew there were ones that would have never bothered. Honestly, it was also embarrassing. I would have to ask a lot of questions to get a sense of what the issue was. The result was often a spotty user account and a lot of their time spent.
How Does Client-Side Logging Make Troubleshooting Easier?
This is an example of a client-side logging workflow using Loupe Server
Broadly, it allows you to collect log data you otherwise couldn’t. You can’t troubleshoot problems you don’t discover. With access to error logs from the browser for each session, you have all the data you need to find problems and improve the user experience before you get significant complaints. But there are specific scenarios/tasks where client-side logging is particularly useful.
When Working With Single-Page Applications
From the user’s point of view, it can be hard to beat the convenience of single-page applications. You only need to load most of the components once and get to work from there, with minimal interruption. But the heavy reliance on JavaScript traditionally makes it very tough to track errors, more so than multi-page web applications, which often lean on JavaScript less.
With client-side logging, you can be sure you catch all of the issues with the application. Because no matter how much testing you do, your users will find ways to use the application you have never thought they would, and all of that action is on the client for single-page applications. I know this because we’ve had unexpected user behavior in our own angular app, and client-side logging helped us discover it.
So much of what happens with single-page applications results from what happens on the client, and having the context available may help you solve problems with the back end. Or at least give them proper context. Instead of errors logged on the server existing in isolation, you can use client-side logs combined with that data, and get a better picture of what happened.
Discovering the Scope of a Client-Side JavaScript Error
Whether an error appears for one user or one thousand users makes a significant difference when prioritizing an error. Client-side logging gives you the ability to make these decisions based on actual data. This works better if you have a log management system that can count the occurrences of a specific error for you instead of doing a hand count. But no matter which situation you are in, the good news is that you have the option.
When Part of a Log Management System
If you have a log management system already, you may have custom notification settings for errors in your applications or a specific error triage workflow in place already. But if you don’t have a form of client-side logging, those errors will be excluded from this process. If you have client-side logging that works with or built into your log management solutions, you can start treating JavaScript errors like any other application error.
-
Set up error notifications. If your client-side logging is integrated with your log monitoring system, you can use the same alert rules for your JavaScript errors as you would for any other error in your application. Whether this means sending a notification to a specific developer or a thread in Microsoft Teams, you now at least have the choice.
-
Easily search your JavaScript logs. Part of a log management system’s appeal is that they make searching your logs much easier than grep or “findstr.” When client-side logging is part of the package, you get the same enhanced search for your JavaScript logs.
-
Make troubleshooting widespread JavaScript errors easier. Powerful log analysis tools that can identify the operating system, the specific machines that had the error, and other metrics across all of your logs can save a significant amount of time. An error that occurred 1,000 times on one machine vs. an error that occurred 1,000 times on 1,000 machines are two vastly different problems that log analysis tools will allow you to identify quickly.
Get a Handle on Your JavaScript Applications
If you have an application that uses JavaScript, client-side logging will help you better understand your application’s health and know errors as they happen, not as you are told. Don’t let yourself be in a position where you are dependent on your users’ goodwill to keep up with your application.
If you have an application using ASP.NET Core, you can learn more about using client-side logging within the Loupe ecosystem. We have built an agent both for general JavaScript applications and a robust agent targeted specifically for Angular.
If you want a free log viewer you can use with your .NET projects, you can try out Loupe Desktop in the link below: