When building apps that connect to APIs, we typically focus on getting the app to work. But what happens when the API is slow, returns errors, or becomes unavailable? The last thing you want is an angry customer calling you when your app breaks. But it’s hard to simulate how your app will handle these scenarios when you don’t control the APIs you integrate with. Unless you use Dev Proxy.
The hard thing about connecting to APIs
These days, it’s hard to imagine an app that’s not connected to an API. We use APIs for everything: from getting data to performing actions. But there’s more to using an API than just making a request and getting a response. It’s only a matter of time when an API you use won’t work as expected. And if you haven’t considered it, you’ll get yourself in trouble. Let me show you how.
You shipped a new web app and it’s working great. But is it really though?
Say, you’re building an app that connects to an API to get products. You also integrate with an external service to get additional product information. In development, you use a dev version of both APIs, which are used only by you and a few other devs on your team. Your app is fast and reliable. It just works. But then, you deploy your app to production. It’s an instant success. In fact, your app is so successful, that the external service you integrate with, can’t handle the load anymore and starts returning errors. Your app breaks. Customers leave displeased and go to a competitor. Could you have predicted this? Could you have built your app differently to handle this scenario?
Simulating API errors and behaviors such as rate limiting or throttling isn’t impossible, but it’s hard. Typically, you don’t control the APIs you integrate with, so to simulate their different behaviors, you end up writing complex mocks – a bunch of code that you won’t be shipping. It’s inefficient, to say the least, but it’s the only way, isn’t it? Not quite.
Simulate API behaviors with Dev Proxy
What if I told you, that there’s a way for you to test how your app handles any behavior, of any API that you connect to, without you having to change a line of code in your app?
Dev Proxy is an API simulator that allows you to simulate different API behaviors, without changing a line of your app’s code. That’s right. Using Dev Proxy, you can simulate errors, delays, rate limiting, and more. All while your app is thinking that it’s connected to a real API! Dev Proxy allows you to ensure that your app won’t fail miserably when the API it connects to breaks. No more calls from angry customers or account managers standing at your desk demanding you drop everything to put out the fire.
How does Dev Proxy work?
Dev Proxy is a web proxy that you run locally on your dev machine. Before you start it, you configure it to monitor requests to specific URLs. Then, you define how it should handle these requests: should it return a predefined response, throw an error, delay the response or simulate rate limiting, or other behaviors? When you start Dev Proxy, it registers itself as your system proxy and intercepts all requests that match the URLs you configured. It then applies the behaviors you defined. Your app doesn’t know that it’s not talking to a real API. It just gets responses as if it was. This makes it for a great way to test how your app handles different API behaviors. Let’s see how you can use Dev Proxy to simulate API behaviors in a sample .NET Aspire app.
Sample case: Improve a .NET Aspire app with Dev Proxy
Consider this sample e-commerce app that’s built with .NET Aspire. It consists of several services, including an API for the product catalog. It implements the default resilience patterns. Let’s use Dev Proxy to simulate different API behaviors to test the default app’s configuration, and improve the app’s resilience.
Let’s begin by starting the app to find out the URL of the product catalog API. We’ll configure Dev Proxy to intercept requests to this URL and simulate different behaviors. The product catalog API is available at http://localhost:5222
.
Simulate API throttling
Let’s start Dev Proxy and configure it to intercept all requests to this URL:
devproxy --urls-to-watch "http://localhost:5222/*"
In this example, we’ll use the default Dev Proxy configuration which simulates several common API errors, as well as latency and throttling. You can control Dev Proxy settings through its configuration file and the collection of plugins that it includes.
Now, let’s restart the .NET Aspire app, configuring it to use Dev Proxy as the system proxy. It’ll route all requests to the product catalog API through Dev Proxy, which will simulate different behaviors.
HTTP_PROXY=http://127.0.0.1:8000 dotnet run --project src/eShop.AppHost/eShop.AppHost.csproj
Let’s start by navigating to the product catalog. Error!
Back in the terminal, we can see that Dev Proxy simulated a 429 Too Many Requests error instructing the client to back off for 5 seconds. While the app has resilience features built-in, it issues several requests in parallel, which makes it seem like it doesn’t respect backing off and causes Dev Proxy to fail the requests. After a few failed attempts to call the API, the app gives up and shows the raw stack trace in the browser.
How can we improve the app’s resilience to handle this scenario? For one, we should consider catching the API exception and displaying it in a user-friendly way. It’ll help us handle not only throttling but also other API errors. We should also consider handling throttling differently, to ensure the app properly backs off and gives the API time to recover.
This is just one scenario that you can simulate with Dev Proxy. You can also simulate other API behaviors, such as latency, rate limiting, and more. This allows you to test how your app handles different API behaviors, without you having to change a line of your app’s code. Using Dev Proxy is a great way to test that your resilience code works as intended when you need it the most.
Summary
When you connect to APIs in your app, you need to think beyond just getting the app to work. It’s only a matter of time when the APIs you use will fail. And when they do, you want to ensure that your app can handle it properly, and won’t lose your customers’ data. Dev Proxy allows you to easily simulate different API behaviors, without you having to change a line of your app’s code. With Dev Proxy you’ll deploy your app to production with confidence, and won’t have to worry about angry customers calling you when your app breaks.
Try Dev Proxy on your app and see for yourself how you can improve it.
You can see it in action on a recent episode of On .NET where we walk through getting started with Dev Proxy and all of eShop:
HI,
is it possible to use dev-proxy to test api calls in a xamarin.forms or maui app running in the android emulator on windows?
We haven’t tested this particular scenario but if the API calls are going over the network stack on the host, and Android emulator supports a proxy, then it should be possible.
Thanks for the reply.
I struggled a bit to setup the proxy in the android emulator, but finally i got i working.
The android emulator itsef has the option to set a proxy in its settings, but that didn't work for me.
Instead i had to set the proxy in the extended wifi settings of the android os running inside the emulator.
Using localhost or 127.0.0.1 won't work here, so use 10.0.2.2 as hostname for the proxy.
This is so cool! Awesome to hear you got it working! Would you be willing to work with us to publish a guidance for this scenario in our docs, similar to https://learn.microsoft.com/microsoft-cloud/dev/dev-proxy/how-to/use-dev-proxy-with-dotnet-docker?pivots=client-operating-system-windows?
Is the option you used to configure the proxy for the emulator an equivalent of the
-http-proxy
command line option that you could use when starting the emulator? Am I correct, that you tried it and haven’t seen any requests intercepted by Dev Proxy?I’ll ask around to see if I can get some more info
Sadly i was a little to quick to say it is working.
With setting the proxy in the wifi settings it does work in the browser on the emulator.
But it won’t work with api requests in my app.
Does this work in Linux containers?
Yes! You can use Dev Proxy with Docker containers too. Here’s some information about how to do it: https://learn.microsoft.com/microsoft-cloud/dev/dev-proxy/how-to/use-dev-proxy-with-dotnet-docker?pivots=client-operating-system-windows. I hope it helps and don’t hesitate to let us know if you have any questions
Interesting.
BTW, the syntax you use to set the HTTP_PROXY environment variable before running the command is specific to bash (and maybe some other shells). Windows users that are not familiar with that syntax might not understand what it does or know how to do the same on Windows. It's great that .NET is no longer limited to Windows, but don't forget that many devs still use Windows as their daily driver 😉.
Good point! Dev Proxy can be used on any OS and with any shell, so of course how you define environment variables will differ. Thank you for bringing it up