During my career as a developer, my focus has been in the creation of the user interfaces for applications: working with User Experience Designers, Graphic Designers, Testers, and other developers to create effective user interfaces for enterprise applications. I have worked hard to create better business experiences for some large corporation clients. But today, we're not going to deal with that. We're going to talk about the relationship between UI and API developers and how you can make the development workflow more effective, and less stressful.

This is my proposal: using a mock API server during application development can assist both UI and API developers with the design, creation, coordination, and testing of great applications.

I've seen a few articles about how to set up a mock API server for different types of projects, and, while I will be writing similar articles like those in the future, this article is focused on what I believe are the good reasons you should do so. As always, good solutions come from practical experiences.

A Revelatory Story

In 2019, I worked on a project with a team contracting with a large corporation to create the UI of a large enterprise Angular/.Net/SaaS application.

Let me try to explain the project was structured so that you can fully understand the problems we were facing as a team. First, there were five teams on the project: a internal client project ownership team, a UI/UX development team (my team), a vendor team providing an API for their software-as-a-service product, a vendor team providing a search solution, and an internal client team providing an orchestration layer to coordinate the data flow.

The inter-team dependencies made our heads spin. Our team was wholly dependent on the orchestration layer team for data, but they, in turn, were dependent on the other two teams to deal with a lot of the data flow and business logic. Making matters worse, product ownership told us that their internal development team's track record on velocity wasn't great. Our team was expected to perform, but we were going to be at the bottom of the priority list.

Early in our process of getting organized for this project, our team decided to create a mock server to mitigate our dependencies on the API teams. We were uncertain we could create any project velocity if we were required to wait for the various teams to produce the data and endpoints we required in a timely manner. And by using a mock API server we were able to reach our goals.

To implement the mock API server we:

  • created a mono repo using Nx
  • added an Angular application for our UI, added a Node application for our mock API
  • added json-server to the Node application to provide the endpoints and data
  • placed our data interface files in a library (created using Nx) which allowed us to share them between the UI and mock API projects

Generally speaking, this setup worked really well and our team performed beyond expectations. We were able to supplement the API team's workload for data design and endpoint responses while decreasing the risk of delays and unmet dependencies.

Why Should You Consider Using a Mock API Server?

This is just one scenario I am relating because it is a fresh experience to me. There are other scenarios to consider which I have also experienced in the past:

  • the project needs to be spun up, but no API developers are available
  • the API developers are occupied with many system integrations and/or new technologies and do not have time to assist the UI team with their needs
  • the project is starting with more UI developers than API developers
  • your API developers are focused on redesigning the API

Basically, any scenario in which your API team is prevented from being able to be responsive to the UI team's needs.

Wait. Before you say "He's all 'me, me, me'. What about my needs?", please read further. This isn't all about the UI team's needs. Using a mock API server can have a positive effect on the full project team.

Using a mock server during development can quickly facilitate:

The Design of Data

Knowing that you are going to be implementing a mock server for the UI team to use during early development means that you can start the discussion about the data structures to be utilized for the endpoints. Instead of the API team being wholly responsible for the design, members of the UI, UX, and API teams can design and create value objects/interfaces early in the project. The API team should have endpoint best practices to guide the endpoint design, and the designed responses and errors can be leveraged for testing for both UI and API teams. The expected responses can be documented early in development making updates and adjustments more efficient.

Reduction of Stress on the Team

Making design decisions an creating endpoints early in the development process can be freeing to all team members. API developers will have a much clearer idea of what data is required before gathering it, and the UI team can plan their development better. Sure, data for endpoints will evolve as the project progresses, and there will be challenges based on unknown factors, but if your team has organized their design efforts properly, the team can begin moving forward confidently. This reduces the stress of the UI team potentially complaining that they do not have the endpoints or data structures they need. And the API team can continue working without a constant stop and go with the UI team. Also, when you've progressed to developing against a deployed server and something breaks that server, your UI team can fire up the mock API server and continue working. None of that "the entire team is waiting on you to fix this" type of stress. And what about working offline? UI developers can work when they have no Internet connection or the company VPN has gone down.

Reduction of Dependencies

The whole team has to depend on each other, but by implementing a mock API server, if, god forbid, your entire API team was "hit by a bus", the UI team can still make forward progress. If there are no UI team members available to connect to the real API endpoints, the API team can confidently test their responses against the designed data responses from the mock API. Yes, coordination and communication will be required, but when you plan correctly, the work can be much smoother than a throw it over the fence approach.

Reduction of Technical Debt

Designing the data structures and endpoint ahead of time, and agreeing upon the structures of responses can be helpful in reducing technical debt. The need for hiding mock data in your code will be eliminated. If you've set your project up properly, both the UI and API can use the exact same interfaces that have been agreed upon, so when changes need to be made to these interfaces, all team members are informed of the changes.

There are probably more reasons to use a mock server during development, but I believe that these points are fairly convincing.

What are the Risks with Using an Mock API Server?

I've thought a lot about the advantages to using a mock API server. But there can be some things that might hamper this initiative:

Your UI and API Developers Do Not Communicate or Coordinate Well

Nothing ever seems to work great on a project where developers do not communicate. Having a developer change a property on an interface without discussing it with the full team isn't helpful, neither would adding data to an endpoint's response. Coordination is required when utilizing a mock API server, otherwise the process becomes an exercise in managing technical debt. You can't have some developers following a plan and others ignoring it.

The Mock API's Endpoints Do Not Match the Production Endpoints (or vise versa)

Again, communication is key to making a mock API work. UI and API developers must agree to the design of the data and endpoints and hold each other to that agreement. If and when it is discovered that new data is needed, or that the designed data may be problematic, developers can not "fix" the problem and "let the other developers deal with it." Sometimes during development the data you want may not be available and adjustments have to be made. There is nothing wrong with bringing up any data issues you encounter when requirements are updated or changed. But adjustments should be discussed and agreed upon by the team.

UI Developers Don't Have the Skills or Experience to Create/Maintain a Mock API

If the API is being built using Java, and your UI developers do not know Java, don't build the mock API in Java. Use a language and server that the UI developers understand and can easily make simple changes. This allows your UI developers to shape the mock data in ways that will help them to test their components and allows the API developers the opportunity to focus their work on the real API.

Maintaining the Mock API

Once a mock API server is implemented, it is difficult to know when to stop using it. If you stop updating the mock API server to match and data design or endpoint changes to match the on-going development, your team may find themselves in a bind very quickly. Make the mock API server a part of your regular development efforts. When an interface property changes, make sure that the task to make that change includes updating the mock API server. Make sure the team takes responsibility for the mock API server.

Please Note: A mock server should never be used in production. Don't even consider it. It will be a disaster. You can deploy it to a development server or QA server at the beginning of your project, and use it to perform stakeholder demos, but at some point the real API has to come online.

In Conclusion

In the future it is my plan to start my new projects with a mock API server when necessary and appropriate, and advocate it on projects where I am a team member. I believe that having a mock API server provides a lot of value, facilitates better communication and design while reducing the stress of internal and external dependencies.

Please consider using a mock API server on your projects.