Resilient Network Calls From The Front-End
Retry all network calls from your front-end to make the app more resilient and reliable
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.
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.
Conclusion
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.
