Faster Iteration with Mock APIs

Scott Becker — Thu, 06 Feb 2020 22:28:09 +0000

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:

{
  "tips": [
    {
      "id": 1,
      "type": "info",
      "title": "Set a daily or weekly reminder to track your time",
      "subtitle": "Tracking",
      "description": "Over time, we can provide insights and suggestions for improvement",
      "link": "https://url/to/set-reminder",
      "label": "Add Reminder"
    },
    // ... more tips
  ]
}

Static Typing

At Olio Apps we've been enjoying TypeScript lately, which allows us to create static types for things like this json structure:

// the tip itself
interface ApiTip {
  readonly id: number
  readonly type: string
  readonly title: string
  readonly subtitle: string
  readonly description: string
  readonly link: string
  readonly label: string
}

// the api response envelope, an object that has an array of tips
interface ApiTips {
  readonly tips: ReadonlyArray<ApiTip>
}

Immutable Data

Note the use of readonly and 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.

API Client

The following function makes a request to fetch tips:

export function getTips(): Promise<HandledResp> {
  if (useMock) {
    return fakeGetTips().then((res: Resp) => handleResp(res))
  }

  return request
    .get(buildUrl("/tips"))
    .set(authHeader())
    .type("application/json")
    .accept("application/json")
    .then((res: Resp) => handleResp(res))
    .catch((res: Resp) => handleResp(res))
  }
}

The Mock API Function

Note the useMock check. If this configuration variable is true, we'll call fakeGetTips() instead of making a request.

Here's what fakeGetTips() looks like:

export function fakeGetTips(): Promise<Resp> {
  const payload: ApiTips = {
    tips: [
      {
        "id": 1,
        "type": "info",
        "title": "Set a daily or weekly reminder to track your time",
        "subtitle": "Tracking",
        "description": "Over time, we can provide insights and suggestions for improvement",
        "link": "https://url/to/set-reminder",
        "label": "Add Reminder"
      },
      // more fake tips
    ],
  }

  return Promise.resolve({
    text: JSON.stringify(payload, null, 4),
    status: 200,
    statusText: "",
  })
}

Just like a standard request, fakeGetTips() return a promise that resolves to a standard response object:

interface Resp {
  readonly text: string
  readonly status: number
  readonly statusText: string
}

Standard Response Handling

In both versions, when the response value comes back in a promise, we handle it with .then((res: Resp) => handleResp(res)).

The 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 status and statusText.

const handleResp = (resp: Resp): HandledResp => {
    // if text present, parse as json, otherwise empty array
    const items: {} = resp.text ? JSON.parse(resp.text) : []
    // return normalized response object
    return ({
        items,
        status: resp.status,
        statusText: resp.statusText,
    })
}

interface HandledResp {
    readonly items: {} // can be any javascript type
    readonly status: number
    readonly statusText: string
}

All downstream functions can now rely on items to be the response data, converted back into a javascript object. Once the 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.

Rapid Prototyping Native Mobile iOS and Android Apps in 5 minutes with React Native and Expo

Scott Becker — Wed, 01 May 2019 21:21:44 +0000

When you have a new idea for an app, you want to get feedback from users as quickly as possible to see if the idea has legs, and start refining it. The best feedback comes once people try it.

So, our primary goal is to make it possible to get real user feedback from people using the app as soon as possible.

In this post, we'll begin creating an app and make it possible to share it with others within 5 minutes so they can give you feedback as you build it.

Secondary goals

Native App - not a responsive web app running in the browser, a fully native app
Skip the app stores - getting an app approved in the app stores is an involved, time-consuming process.

Given these goals, one of the best sets of tools available today is React Native and Expo.

React is a declarative, efficient, and flexible JavaScript library for building user interfaces.

React Native is a framework for building native iOS and Android apps using React.

Expo is a tool for creating React Native apps quickly. With Expo, you can start a new app, preview it in the browser, then see it on your own device, and share it with others almost immediately (5 minutes).

Get a taste with Snack

Snack is a lightweight online IDE for Expo that allows you to run code in the browser in a matter of seconds. It's great for quick experiments and sharing examples.

Go to snack.expo.io. You'll see some code, and an image of an iPhone, with a large "Tap to play" button. Tap it, and the app will boot in a device simulator.

Change the text in the code and it will update.

Install the Expo toolchain

First, install Node.js. The latest version is recommended.

Second, install the Expo package for Node.

npm install expo-cli --global

Third, install the expo mobile app on your device. Either iOS or Android.

Create a new app

Once everything is installed, you can run the following commands from your terminal to get a new app running in development.

expo init my-new-project
cd my-new-project
expo start

Scan app QR code to run it on device

You will see a QR code in terminal and Dev Tools. To open your project on your device, simply scan the QR code with the Expo Client app on Android or using the built-in QR code scanner of the Camera app on iOS.

See your changes immediately

Edit the home screen screens/HomeScreen.js
Watch your device refresh

Notice what we did not do

No Apple developer program registration ($99 + days)
No creating code signing certificates
No cable from the computer to the device
No compiling in Xcode
No uploading to TestFlight
No inviting users to TestFlight
No app store review process

Of course, we will want to do these things too, but only when we are ready to launch. By that time, we will have validated and improved our idea with real user feedback so it can be truly great.

And we won't have to start over with a different platform or framework to get there. React Native and Expo supports the full life cycle from development to app store deployment.

Do you need an app prototyped or built fast? Olio Apps can help. We have built and shipped multiple iOS and Android apps to the app store. Tell us about your project!

DEV Community: Scott Becker