By craig | March 16, 2020
Welcome to ServeUp!
ServeUp is a macOS application that can be used by iOS and Android developers (and others) to serve mock responses to iOS or Android applications.
The problem ServeUp solves
Almost every mobile app developer has to fetch (or update) data from a remote server via remote APIs. The mobile app under development is tightly coupled to a) the existence of these remote APIs, b) the stability/reliability of the APIs, and c) the types of data that is returned from the APIs.
Unavailability/unreliability of APIs leads directly to a significant loss in developer productivity. Insufficient test data being returned from the APIs also reduces overall product quality (for example, it is difficult to test how the app reacts to various response codes and data conditions).
ServeUp is a macOS app that offers the ability to serve static and dynamic responses to mobile apps based on inbound requests. Typical usage of ServeUp would look something like:
- Identify the APIs that need to be mocked
- Capture (or create) sample responses for each API
- Configure ServeUp so that it maps inbound requests to responses
- Configure mobile app to point to ServeUp as API server (eg. https://localhost:8080)
The mapping between a request and a response is called a route. ServeUp supports sophisticated pattern matching techniques to determine which response should be served back to the phone for each request. At the most basic level of use, ServeUp might have a one-to-one mapping between an inbound URL and a response file. For example, for a mobile app that calls some user-based APIs:
/api/v1/listUsers might return the contents of a file called
/api/v1/saveUser might return the contents of a file called
When ServeUp receives an inbound network request it iterates through the routes until it finds one that matches the incoming request. That route definition then describes what response should be sent back to the caller.
Why should you use ServeUp?
ServeUp offers the following advantages over other mechanisms for mocking responses:
- An intuitive UI that makes it easy to make changes
- Changes can be made quickly, and are effective immediately, without the need to stop, recompile the app, and resume again
- ServeUp responses are able to easily be shared between iOS and Android apps
Creating Your First Route
Conceptually, you can think of ServeUp as a web server that is able to respond with specific responses based on the incoming request.
In order to do this, you first need to create a route that represents the matching criteria for an inbound request, and how it should be handled. To create a route, click on the
+ button in the toolbar. This will add a new route into your route list.
If you change the match type to
Equals and the path to
/some/path this route will match any incoming requests to
Click on the Handling tab to define how this route will handle these requests. Set the type to be Static Text, the content to be
<html>hi there</html> and the mime type to be
Save your configuration by pressing
⌘S, and click on the Start Server button (or press
⌘R). In a browser, paste the following URL:
http://localhost:8080/some/path and you should see hi there displayed in the browser.
Congratulations, you’ve successfully configured ServeUp!
The example above returns static text in response to a request, however a much better approach is to return the contents of a file.
In the Handling tab, you can choose a file that will be streamed back to the caller.
You can use the
+ button to the right to select a new file, or you can drag and drop a file (or multiple files) onto the ServeUp document window. This will make copies of the file(s) that you can then select from the drop-down menu.
Everytime a request comes into ServeUp a record gets added to the Request History tab in the bottom pane. For example, in the screenshot below, there have been three requests to the same URL.
The Request/Response tabs on the right show the data that was received/sent.
By clicking on the icon, ServeUp will display some information about why the incoming requests did/didn’t match each route. This is very useful for debugging why incoming requests do not match routes as expected. In the example below, there are a couple of routes that did not match the incoming request.