Nerd For Tech
Published in

Nerd For Tech

Resilient Network Calls From The Front-End

Retry all network calls from your front-end to make the app more resilient and reliable

Photo by Denny Müller on Unsplash

The front-end applications we build mostly rely on active internet connection, in order to access the server and get or post data. Once the data is retrieved, we can do a bunch of stuff locally, such as animations, transitions, validations and so on. We are so used on reliable internet connection, that we often disregard the fact that the network call we do from our front-end to the server-side is maybe the most unreliable part of the application. We need to treat it as such, because it can fail at any time (rarely, but it can).
It could happen that the user accesses your application from a phone, which is switching from Wi-Fi to mobile data at that point, or is in a low coverage area.
In these situations, the network call your application was trying to do could fail, and the user will see a nice error message, asking him to try again. The user refreshes the screen or clicks the button again, and the app works like nothing happened. You say job done and move on to the next feature.

Just a scratch for the Yugo

But you can do better here. Your application can retry instead of the user, thus improving the UX.

Automatically retry failed requests

We can do a simple interceptor that will intercept all HTTP requests. If an error is encountered, it can retry before throwing the error.

The user might wait more, but maybe that’s better than showing errors. Also, the user might be aware that his device is switching to Wi-Fi or that he is in a low-signal area.

The interceptor above is very basic and will retry everything. But we can further improve it.
If the error is 4xx, that usually means it’s the client that’s at fault, and retrying 1000 times won’t fix the issue. We can thus skip retrying if that’s the case.
Also, in the simple example above we just retry after 1 second, which is too long of a time. Instead, we can retry once or twice very fast, and than back-off and retry one or two more times with bigger delays. That way, if it is a temporary error, it will be resolved right away with the fast retries, or as a last hope after the backed off delay. But we should be careful to not let the user wait for too long, or they might think the app is not responsive.
And as a final UX improvement, when we retry, we can add a small text next to the progress loader that will say something along the lines of “Slow connection detected, please be patient” or “Server is busy, please hang on”. That way we will give feedback to the user that the application is not stuck or not responsive, but indeed it is trying its best to get the job done.


Most applications will work without features like this. And they can be successful, because they get the job done. But little things like this can nudge your thinking to always cover edge cases, even before they appear.
Another important point is that this is done globally, so all new network calls will be more resilient without even the developer knowing it.




NFT is an Educational Media House. Our mission is to bring the invaluable knowledge and experiences of experts from all over the world to the novice. To know more about us, visit

Recommended from Medium

Solid Dry Kiss Yagni — Engineering Principles

Top ten Docker images contain over 8000 vulnerable paths | Snyk

Systemd Service Failure Notification System

Differences Between Monolithic and Micro-Service Architectures

Infrastructure as Code

Walking through Coding Problems with Corgis.

code with corgis

Ruby on Rails Installation on Ubuntu

Here’s the Study Plan a Self-Taught Software Engineer Used to Get Two FAANG Offers

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Boris Donev

Boris Donev

As a technical team lead of several startup projects, I've come across different issues which I'll try to document and maybe help someone else.

More from Medium

Angular with Jest Testing

Intro To JavaScript Unit Testing

Testing DOM mutations with Jest

Difference between React js and Angular: A comparison guide for 2022

Difference Between React js and Angular 2022