12 Implementing frontend code and reacting to changes

 

This chapter covers

  • Building the frontend against a mock server (Prism) based on OpenAPI
  • Identifying design issues found during implementation
  • Using OpenAPI examples to verify that API changes make sense

When we separate a web application into frontend and backend, we create a dependency issue. The backend often needs to be built first, before the frontend can start. In this chapter, we’re going to look at how we can build the frontend without having the backend implemented. This will free us up to start developing straight away. It’ll also allow us to catch design issues sooner, while it’s still cheap to add them into the backend.

Before we build the frontend, however, we have several options to consider, mostly related to the question, “Where should we mock?” We have the following options:

  • Mock the data on the view layer.
  • Mock the data in a central data store (think Redux, MobX, RxJS, etc.).
  • Set up a mock API server.

The first option is the quickest, but the messiest. We’d need to be careful about where we’ve added mock data and when we remove it. That approach should only be used for very short-lived tests.

Mocking data in a central data store is better, since we have one place where it’ll be mocked. This would allow us to also toggle it on and off in code when it comes time to integrate with the backend. The downside is that we still have mock code in our source files.

12.1 The problem

12.2 Setting up Prism

12.2.1 Installing Prism

12.2.2 Verifying that Prism works

12.3 Building a frontend based on a mock server

12.3.1 Adding multiple examples into your OpenAPI definition

12.3.2 Using examples in Prism

12.4 Identifying a missing API operation

12.4.1 Due diligence for adding the operation

12.4.2 Designing the new operation