Ever wondered how to debug an app while it's running in production? Fiddler Everywhere helps you do just that... without impacting your production systems!
If you've been following along with us in this blog series, you'll know I'm a pretty big fan of the Fiddler family. The ability to inspect and debug HTTP/S requests and responses from apps of all types (desktop, web, and mobile) can be a critical part of our development and debugging experience.
Fiddler Everywhere is a cross-platform tool that includes a revamped experience that performs identically across macOS, Linux, and Windows.
NOTE: Fiddler Classic (the original Fiddler) isn't going anywhere! You can still download Fiddler Classic and use it like you always have on Windows.
Today brings us to part four of common debugging scenarios many of us have encountered. We experience failures from remote APIs, we look for 404 and 500 errors, and, like today, are trying to replicate and resolve customer-reported issues while an app is already in production. Yikes! 😨
If you're just tuning in, be sure to check out some other posts from this series:
While on the subject of new Fiddler family tooling—take a look at Fiddler Jam if you're interested in inspecting remote customer issues!
On to the dreaded issue of not being able to replicate a production error locally. We've all been there. When we can't effectively diagnose a production-level error, it's obviously difficult to then debug, test, and ultimately resolve, a change.
As a web developer, I've seen some issues pop up from customers that show an error in the production environment for my app. Unfortunately, with the information I have, it's virtually impossible for me to replicate the issue locally due to one of the following factors.
The error only seems to happen...
Using Fiddler Everywhere, we are going to fake out our application and make it think that it is running in production. But instead of loading key assets from our production environment, we are going to tell our production app to load them from a different source (in this case our local desktop).
This way we can run most of the app "in production," while loading individual scripts/files/whatever we suspect as being the culprits, from our local development machine. To do this we can take advantage of Fiddler Everywhere's Auto Responder feature.
The AutoResponder feature has been updated and renamed to Rule Builder as of July 2021.
Let's see how this works in practice:
Open Fiddler Everywhere and toggle the Live Traffic option to Capturing:
In your favorite browser, open the website in question and make sure all of the suspected problem assets are loaded by navigating to whichever page(s) are throwing errors. Remember, this could be JavaScript bundles, resources served by a CDN, images, or any other components of your application.
Back in Fiddler Everywhere, toggle the Live Traffic option to Paused so as to limit new requests coming into our session pane.
I mean, the app is using Bower as its package manager! Maybe the error we are looking for is the least of its concerns... 😀
Find the specific session(s) you are interested in. In my case, I'm going to filter by URL to only show me the app.js bundle, which is a minified JavaScript file with my core app logic (a key suspect in the case):
Next I want to build an Auto Responder rule that will capture a request and do something, anything, with it. Right-click the session identified and choose Add New Rule.
Now, navigate to the Auto Responder tab where you'll see the session URL pre-loaded for you. Edit the rule and in the Action field, paste the location of the file you want to serve from your local file system. For instance:
C:\Users\myuser\Documents\app_unminified.js/User/myuser/Documents/apps/app_unminified.jsSave the rule, make sure Enable Auto Responses is checked, head back to your website, and reload! Fiddler Everywhere will intercept the request and replace the remotely-served file with the specified one from your own file system.
In theory, this allows you to quickly and easily substitute any resource with any other resource like images, videos, libraries, text, etc.
Auto Responder can do more than just swap out files. Take a look at additional Auto Responder actions that you can experiment with today:
We took a quick look at how Fiddler Everywhere can be used to diagnose possible issues in production, without negatively impacting existing users or the production system itself.
Want some next steps?
A maker at heart and a supporter of the open web, Rob is Developer Relations Lead at Blues Wireless. You can find Rob rambling incoherently on Twitter @RobLauer.