Developing an application and an API in parallel can be quite the tricky task. Often times, it can lead to misunderstandings and miscommunication between developers. This can cause a project’s progress to come to a screeching halt. The longer the misconceptions go unnoticed, the bigger the damage may be.
On recent projects, my team has begun to use fake APIs. A fake API is a simple representation of the API that is being built for production. I’ve found that the use of fake APIs has been enormously helpful for myself, my team, and the project as a whole. Although there are several great benefits to creating a fake API, I’m going into detail on three specific benefits.
- Fake APIs Open Lines of Communication
- Fake APIs Allow for Parallelization
- Fake APIs Expose Problems in their Early Stages
Fake APIs do wonders for communication. With a faux API in place, both the application developer and the API developer know what is expected of them. The application developer knows what kind of data they can expect to receive, and the API developer knows exactly how they need to structure data for the application.
Not only does it draw a clear line in the sand, but a fake API also creates meaningful, passionate conversation. Whenever I (as the API developer) have a question or opinion about the structure of the data for the application, I can talk to the application developer to realign our opinions. This can often be augmented by a quick 5-minute whiteboard session. After 5 minutes, I have a clear direction on where I am going with the production API, while the application developer has a clear direction on what to expect from the API. There are no misconceptions and no lost work as a result.
The progress of an API and an application always seems to be a balancing act. If the application gets too far ahead, the API is fighting to catch up while application development slows. When the API gets too far in front of the application, a change in design of the application can cause massive amounts of rework in the API. A project in the early stages can suffer from this pain the worst. The API and the application have nearly identical progress, and both developers are racing to get out ahead to catch a breath of air. Fake APIs help alleviate this pain.
Fake APIs allow developers to continue at a sustainable pace in parallel. The application developer doesn’t have to be worried if the API developer hits a snag, and vice versa. As long as both developers have agreed upon the data the API should return, the application developer can continue on their merry way implementing new features while the API developer adapts the API to meet the applications needs.
Fake APIs are meant to be simple, and they probably use some sort of static or random data. But don’t take this simplicity for granted. Even a simple fake API can bring lots of concerns to light. A fake API forces both sides to think about architecture. It reveals patterns in data structures that allow for abstractions later in development. The fake API can reveal holes in assumptions made, and it can also uncover areas of the application that require more thought than initially anticipated. Sure developing the two production units side-by-side can point out these same types of flaws, but personally I’d much rather learn these flaws with simple, fake data before I’ve implemented half of the real thing.
Next time you’re starting a project that requires an API, give some thought into creating a fake API. So far, I’ve thoroughly enjoyed this approach, and I’ve been astonished at the results in both quality and accomplishment.