Microsoft’s Dev Proxy puts APIs to the test

Much of modern application development depends on APIs. In the past we may have built massive monolithic applications, but modern cloud-native development depends on collections of microservices, linked by APIs that offer everything from remote procedure calls to database operations.

This approach makes applications easier to run, allowing them to scale with user demand. It also makes them more reliable, handling failover in the event of data center outages. But it makes it harder for developers, as agile software development methods break apart those services across teams while also demanding test-driven approaches to code. An application component may be ready to test, but the services it uses might not be finished. The application might also need a third-party API that has associated costs that may not be acceptable during development.

Simulation and proxies

How does a front-end development move forward without working business logic so that developers are still productive, and product and project managers can ensure that parallel developments continue? One possibility is to build on top of mocks, with dummy APIs that simulate the operation of a specific server. Building new mocks can take as much time as building the service, so what’s needed is a quick, easy-to-use service that can provide the necessary tools between client and server and can be built into familiar development tools.

The answer is an API simulator, a generic tool that’s part of your development tools, intercepting network calls, delivering expected responses, testing out your code’s responses to various classes of error, and simulating the types of API management your code may need to work with. If there’s a specification for an API, a simulator can implement it for you so you don’t have to write mocks or spend development budget on subscriptions to third-party APIs before you need to.

A tool like this can work as a true proxy, sitting between a live API and a development environment. It can also inject errors into API responses and simulate throttling so you can add a little chaos into otherwise predictable operations.

Microsoft recently released an updated version of such a tool: Dev Proxy v2.0 (not to be confused with its similarly named Dev Tunnels). It’s a major release, as there are breaking changes. A big release means significant new features and support for the latest.NET release. If you’ve used earlier releases to test out services like the Microsoft Graph APIs, there were issues as the proxy application didn’t deliver results that were consistent with the live service. Where the Graph APIs used RFC 1123 and ISO 8601 date formats, Dev Proxy used your local PC’s own date formats, so if you were in the UK you’d get different results from someone in the US—and neither would be aligned with the actual service outputs.

Getting started with Dev Proxy

You can install the new Dev Proxy release using Windows’ package manager WinGet. This is easier than the manual option (downloading from GitHub and editing the required environment variables by hand) as the install script sets these up for you. As you’re using the Windows command line to run WinGet, restart it once installed to reload your environment without rebooting your PC. Even with WinGet, the first time you run Dev Proxy you’ll need to trust and install its security certificate before letting it through the Windows firewall.

The default configuration works with the useful (and free) JSONPlaceholder service, trapping requests and applying a simulated throttling with a 50% error rate. Microsoft suggests manually sending a GET request to its API, using either PowerShell or a Windows implementation of curl. If you prefer, you can use API tools like Postman to send requests and view responses. Dev Proxy will show either a pass through or an error on the command line.

The key to getting the most out of Dev Proxy is its configuration. You can have several different files and load the one you want to use at startup; you can run different tests with one service or tests for different services. Building a library of tests and sharing them with colleagues is a good idea as it can speed up building tests and provide a set of templates that can adapt to new projects.

There are three parts to a Dev Proxy configuration. The first is common to all configurations and details the schema used for configuration. This needs to be the version for the Dev Proxy release you’re using and a link to the file on GitHub. Next is a list of the plug-ins being used. Finally, the application configuration data: the APIs being watched, the errors being injected, and the rate limit that’s applied to calls. Plug-ins may have their own configuration data that’s applied when the plug-in is loaded.

One key feature of Dev Proxy is that it’s selective. You can let some API calls pass through, apply errors and rate limits to others, and intercept still more, redirecting calls to Dev Proxy-hosted mocks. This flexibility allows you to pick and choose what is tested and how. Finding the APIs to intercept requires using the proxy as a transparent proxy, discovering and recording all requests from a specific process. (You need to specify this, as otherwise Dev Proxy will record all network requests from every application on your PC.)

Armed with a list of URLs, you can now add the tests you want to apply to your code, intercepting requests for specific addresses and delivering mock responses. You first need to load the MockResponsePlugin and give it a list of API calls and the associated responses.

Using plug-ins

Dev Proxy’s plug-in architecture allows you to add additional features to a proxy so you can use much more complex mocks than simple response lists, for example, implementing a basic API for reading and writing to a database or even using an AI API. Others allow you to simulate using authentication or help ensure that you’re using the minimum permissions needed to access confidential and personally identifiable information.

Plug-ins don’t necessarily implement mocks. They can temporarily add telemetry that isn’t normally available to an application. For example, if you’re using it with Azure OpenAI, you can install a plug-in that helps record interactions with what can be an expensive service to use, providing telemetry and recording usage in CSV files for further analysis outside of your development toolkit. The OpenAI telemetry plug-in now also tracks cached tokens, ensuring you can track exactly how its APIs are being used. This helps predict how much token usage will cost in production.

Dev Proxy is a surprisingly powerful tool with a lot of useful features. It seems simple at first, but the combination of its plug-ins and its ability to inject errors and rate limiting into API calls allows you to simulate a wide selection of different API operating modes. Plus, Microsoft publishes instructions for building your own plug-ins. If you need something that isn’t available in the downloaded set, you can write your own.

Using the Dev Proxy Toolkit

If you’re using Visual Studio Code to build your microservices with whatever language or framework you want, you will want to install the Dev Proxy Toolkit. This provides tools for configuring and managing Dev Proxy, as well as installing it if it’s not currently available on your development PC. You can use the toolkit to edit configuration files and use the Visual Studio Code command palette to start, stop, and control the proxy. You can even watch for URLs that you might want to build proxies and mocks for. Other options include a library of JSON snippets to help add specific function to the proxy via its configuration.

If you want to work with GitHub Copilot Agent, there’s even a Model Context Protocol (MCP) server that can be installed alongside the toolkit and the proxy. This provides help while building configurations and can generate new configurations from natural language prompts.

Tools like Dev Proxy are an important part of the modern development tool chain. Distributed application development requires some thought and is hard to build out at a service level. Dev Proxy can be configured to behave differently as you move through the software development life cycle or as other application components are deployed in tests or in production. Add a set of development tools for Visual Studio Code and an MCP server, and you get tools that simplify development and make Dev Proxy an easy choice.