Today we live in a world of service-oriented architecture, often with some sort of single page application (SPA) or mobile application on the front end. Those clients call to our backends running in the cloud. This is pretty much the pattern we see in many of the systems we build today.
A majority of systems have more than a single client and a single set of backend services, but they often have — at a minimum — some sort of client calling a backend service.
To reduce risk while building these systems, a common pattern is to build the UI first. This method has a few huge benefits by reducing the risk of:
- not building what the user expects
- building a UI that will be more difficult than expected
- getting the interaction wrong between the client and the server
Often the question of “where should we mock?” comes up. Should we mock at the client layer or the backend service layer?
But there is another option: we can mock at the API Management layer.
How do we do this?
Microsoft provides a really good guide for getting started with this.
While this isn’t the most obvious solution for mocking, it does allow us to have mocking on the server side without waiting until we have some backend .NET code running. This should enable developers to set up APIs before the project ever gets going. Using API Management to create a good mocking layer would provide something for SPA developers to code against and would serve as a good definition for what the server needs to return.