As a developer, you want your web application to work. That may be an obvious statement, but it leads to an important question: How exactly do you go about ensuring that? For many developers, the following scenario may seem familiar.
You create your application and test it locally. Great! It works locally. You then make sure it runs in production. Because you’re thorough, you make sure it works in multiple browsers. After that process, you’ve done all you can. That must mean it works, right?
That’s what you think until users begin reporting errors. You’re then forced into the tedious position of trying to reproduce those errors. Since your app uses third party APIs, you’ll be lucky if you can actually do so.
If this situation is all too familiar to you, you should be interested in API monitoring. Unfortunately, the most common way of monitoring, server-side monitoring, comes with caveats. With server-side monitoring, you’ll only be getting insight for APIs calls made from the server, not the client. What you truly want is to see what’s happening on their machine.
Luckily, with client-side monitoring, you can get the client-side perspective you could only get from seeing their developer console. It’ll give you the reach of server-side monitoring while showing you exactly what your users are seeing on their end.
In this post, we’ll be showing exactly how client-side monitoring can help you monitor your user’s experience while using your application.
Developer Tools Only Shows Your Computer
If you were on the user’s machine, you’d have access to useful developer tools. Unfortunately, the only developer tools you can usually access are the ones tied to your local machine and session.
For example, we can use the home page of the Star Wars API to make some sample requests to that API. As we do so, we can see the request information in this tab.
You get an accurate perspective of what’s going on from the client’s point of view. Unfortunately, as you’re the client in this scenario, it won’t be particularly enlightening for monitoring your application’s actual usage. After all, you can’t see a customer’s developer console. For that reason, most monitoring is done on the server’s side.
Server-side Monitoring is Powerful
When someone monitors their API, they typically do so from a server. Server-side monitoring gives you the ability to monitor your app in a controlled environment. You control where the call originates, and you’re in control of the server the calls are coming from. From simple unit-testing to full integration testing, you can use server-side monitoring to ensure your application is running smoothly with sample calls.
This process of synthetic monitoring can give you more insights into what potential calls your users could be making. However, it's more accurate to be monitoring live calls. By doing so, you’ll get insights into how your API is handling requests. That’s one of the reasons why synthetic monitoring is not enough
That said, you’ll only be getting live updates from your server’s perspective. For this reason, there are some additional advantages to using client-side monitoring.
Client-side Monitoring is Possible
Server-side monitoring lets you test a vast array of calls, catching errors in the process. Wouldn’t it be great if server-side monitoring also gave you access to that wealth of information provided in a user’s developer tools? Well, if you want that type of monitoring, you’ll want to utilize client-side monitoring.
With client-side monitoring, you get visibility into every call that happens from your app’s frontend. You can monitor the errors users are getting, and have all the information available to try troubleshooting the issue.
It’s never good when a user informs you that your website isn’t working for them. With client-side monitoring, you’ll be able to stay on top of those errors as they arise. Whether there’s an error with your own API or its integration with third-party services, you can address the issue instead of letting it fester, frustrating users on your website without your knowledge.