Faster Iteration with Mock APIs
When and how to make mock APIs to improve work efficiency
By Scott Becker — originally published January 7th, 2018
We frequently work on front-ends along side other teams building APIs. Sometimes those APIs are not yet available. But deadlines and sprint demos are approaching. Are we to sit around twiddling our thumbs? Nope!
The approach we take is to get the API spec if available, or if not, imagine how we would want this API to look and behave.
Then we create mock API functions within our front-end application that do not make any requests, but behave exactly as if calling the real API, returning fake data.
An alternative is to use a hosted fake API server like json-server. In some cases, that might be a better choice — such as if the front-end is deployed to a staging site, and you want to be able to edit the fake responses without redeploying.
During the development phase, we prefer to use mocking functions instead, so we don’t increase our dependencies or have to rely on an external service for testing.
This allows us to decouple our development process from that of other teams we are relying on, and quickly put together working demos that illustrate how the application will perform once the API is online.
Example API — a list of tips
Suppose our backend API will return a set of “tips”. A tip is a short piece of content, to show to a user on start up. Think Clippy or, a “Did you know? …” pop-up. The front end application will fetch these tips from the API and show them to the user.
We have mockups, but the API is still under development. Fortunately, the shape and contract of the API is known. If we build the UI to be data driven now, we won’t have to go back and do partial rework later. When the API comes online, we can flip a switch and it should “just work”.
API response shape
This API will exist on an authenticated HTTPS endpoint. Let’s say its
GET https://special.api/tips. According to the spec, the response JSON shape will be:
At Olio Apps we’ve been enjoying TypeScript lately, which allows us to create static types for things like this json structure:
Note the use of
ReadonlyArray<T> which enforce immutability. We use tslint-immutable to ensure all data types are immutable and checked at compile time, instead of at run time with something like Immutable.js. This yields higher performance and more straightforward code.
The following function makes a request to fetch tips:
The Mock API Function
useMock check. If this configuration variable is
true, we’ll call
fakeGetTips() instead of making a request.
fakeGetTips() looks like:
Just like a standard request,
fakeGetTips() return a promise that resolves to a standard response object:
Standard Response Handling
In both versions, when the response value comes back in a promise, we handle it with
.then((res: Resp) => handleResp(res)).
handleResp function converts the response object into a normalized structure, where any text from the response is parsed as json and returned as
items, along with the
All downstream functions can now rely on
tips API comes online, we can simply change
useMock to false, and it should work as long as the API data structure hasn’t changed.
Originally published at www.olioapps.com.