Is there any pattern for handling network error when sending requests?

Publish Date: Jun 20 '19

Hi everyone, so cool to have you back here on Dev.

Today I wanted to speak about something that I thought and never tried to test in a real app.

Let's say I am answering an email. I opened my web app and log to Gmail for example.

My network is fine, I type my answer and while the time goes by I am having a network failure. The app did not warned me, and I press "send".

How would you tackle this?

In one hand, the classic way is to catch the 500 and inform the user nothing can go on for the moment.

Gmail in another hand is putting the request in queue and will send the email as soon as possible.

What do you think about it?

Is there a good way to handle network fluctuations while sending requests to the server, so the user have the best experience possible?
What about queueing requests in the browser cache, and sending them as soon as the network is ok?
Do you think retry strategies, like n retry then fail would fit client-to-server architecture?

Comments 4 total

rhymesJun 20, 2019

Gmail in another hand is putting the request in queue and will send the email as soon as possible.

If you notice in Gmail you can do whatever you want once you pressed send and you have 30 seconds to undo if you enabled that feature. I suspect they use both web workers and service workers.

Basically a worker is an escape hatch for the fact that JS runs on a single thread, allowing you to use multiple threads for computations.

This is a great intro to web workers: Web Workers in the Real World.

This is a great intro to service workers: Service Workers: an Introduction

There is a Background Sync API which I think it's what you're talking about but it's a Chromium only API: caniuse.com/#feat=background-sync so you probably have to do search for a polyfill or do it yourself.

Another possibility would be to use a service like AWS AppSync I guess, but I've never tried it.

Is there a good way to handle network fluctuations while sending requests to the server, so the user have the best experience possible?

You can detect if you're online and offline with navigator.onLine. You could find more with the Network information API but it's basically a Chrome (and mostly Android) only feature.

What about queueing requests in the browser cache, and sending them as soon as the network is ok?

As cache in this context you mean persist them in the local storage or the service worker cache?

Do you think retry strategies, like n retry then fail would fit client-to-server architecture?

Yeah, why not, probably you can use waitUntil
- AnwarJun 21, 2019
  
  About the concept of queuing requests in the cache, waiting to send them when the network condition are good, I also thought about the Cache API but I wondered is there any tool of pattern or does someone already implemented it on his app.
  
  Same for the retry strategies. I thought about it because I am also working on Service Workers. Workbox inspired me with their cache strategies and the usage of the Background Sync API like you mentioned.
  
  Also, something I read got me thinking for the moment such a retry features might be browser-opiniated because (developers.google.com/web/updates/...):
  
  Retry syncs also wait for connectivity, and employ an exponential back-off.
  
  So If I understand correctly, and I managed to see this behavior when I worked on a service worker library, on Chrome I notice kind of an exponential time for retries when I shut down my network and register cache strategies on my web page. Interesting.
  - rhymesJun 21, 2019
    
    I also thought about the Cache API but I wondered is there any tool of pattern or does someone already implemented it on his app.
    
    Isn't that what the service worker does? Using the cache API
    
    So If I understand correctly, and I managed to see this behavior when I worked on a service worker library, on Chrome I notice kind of an exponential time for retries when I shut down my network and register cache strategies on my web page. Interesting.
    
    Exponential backoff for retry strategies is a good way to avoid flooding the upstream server. If the server is telling you "I'm having issues", flooding it with a request every N milliseconds it's not going to help the server (you end up creating a denial of service) nor the user experience (too many requests and errors to show)
    - AnwarJun 21, 2019
      
      Yes exactly, the service worker is taking advantage of the Cache API to handle network issues, you only need to implement the algorithm or use Workbox.js.
      
      I guess exponential retry strategy is good. I wonder if there is variants like "up to a certain number of retry" etc... Really exciting, thanks to Service Workers we are closer to native app experience! I hope others browsers will support the Background Sync API soon!

Add comment

Anwar @anwar_nairi

Is there any pattern for handling network error when sending requests?

How would you tackle this?

Comments 4 total