What you might learn about your APP by delaying or throttling API responses.

So, you created a frontend application or web application. You spent a lot of time choosing which framework to pick. You learned all the dos and don'ts as well as a number of best practices that you could find. Now you want to know about some real-world test scenarios you might put it through before letting it go into production and that is how you came up with the idea or need to test something related to the network connection.

Or you are already running an app in production and from time to time you are getting user errors or reports that seem to be related to poor network connections with low bandwidth or high latency.

Delay or throttle your API requests to simulate production environments and gain new insight about possible issues in your app.

As a software development company focused on both web and mobile app development, we are doing a lot of JavaScript development for the front- and backend. Therefore this post is focused on SPA development.

We want to share one kind of test we usually use throughout the development process when building web or mobile apps. Of course this is not only a test you can run on existing apps or codebases, it is more a scenario you can and should think of every time when implementing an API interaction.

Photo by Icons8 Team on Unsplash

Did you fall for the illusion of a perfect network connection?

When a Single Page Application is built, this usually happens on the local machine of a developer. No matter if Angular, Vue or React, the developer will run a local build job and something will serve the application locally. In addition, when the SPA connects to an API, it usually connects to an API on a development server with a very stable and fast network connection. For example a development API on the same machine.

So let's look into how we can get at least one step closer to simulate a real world scenario for our apps during development.

This stable and predictable network setup is great to not get in a developers way while coding, but it can also mislead in various ways. It might make you forget that in the real world of end-user connectivity:

• The API is not always available for the web or mobile app
• Not every response takes below 200ms to arrive at the frontend app
• The responses do not always arrive in the order of the requests
• Not every request is successful
• The network connection is not stable or predictable in general

So during development, we all are usually coding in our little cozy bubble of perfect network connections, meaning we have low latency, high bandwidth and perfect reliability. Which is good because this allows us to focus on what we are building without distractions. But for a web or mobile app in real life, things look a little different and there is no advantage in hiding from the complexities of the outside world. Bad or no network connectivity at all is only one of the factors that will hit an app really hard when it has not been prepared to properly run out in the wild. Of course those differences are usually more relevant for mobile apps or web apps on mobile devices compared to desktop use cases.

Simulating a real-world scenario

Let's visualize what difference we actually want to reproduce while developing and testing an application. The scenario during development for multiple requests in parallel looks like this.

The only deviation might be a tiny little difference in response times, amounting to some milliseconds in total. But some things will nearly always stay the same when running this app in a development environment.

• All Request will finish successfully (at least on the network layer)
• Orders request is going to be finished before the customers request
• Orders and customers requests will both be finished before the user starts interacting with the App UI
• Autocomplete requests will be finished quickly and will not overlap

But in production, this is what actually might happen

Here we see an entirely different timeline.

The main differences are

• Orders request finishes after customers request even though it has been started earlier
• Orders and customers requests are still pending when user interaction already starts
• Orders requests overlap with autocomplete request
• Autocomplete requests overlap with each other
• Everything takes longer

Of course, even this scenario is by far not the most complex one. Requests might completely fail or timeout when using a web or mobile application in the real world.

What you might learn about your application

When switching from a perfect environment to a more unstable one in your web or mobile app development process, you will most likely notice that you did not code as defensively as possibly necessary. Of course, defensive coding in general and sticking with the best practices and standard patterns of asynchronous operations can prevent a lot of those issues. But in a complex application with a lot of business cases using the same API endpoints in different combinations depending on how the user interacts with the UI, it is very likely that some scenarios go unnoticed.

So what you might learn by throttling or delaying the API is

• Not all of your loading indicators are working as perfect as you thought
• You have unexpected side effects when requests overlap or take a very long time
• Your state management (especially reducers) may need some improvements to be ready for API delay related scenario
• You might need to improve your UI and UX for those scenarios as well

For those who'd like a bit more chaos

If delaying or throttling is not enough for you and you want the real user experience including edge cases some users might experience you need to go one step further into chaos mode. And you are right to test that, at least from our perspective.

Imagine your request/response timeline looks like shown below, will your frontend application still do something that makes sense to the user?

How to throttle an API

If you are convinced by now that you should try this out and test your web or mobile app with throttled api responses, but you need a starting point on how to do that, here are two options that should get you going.