re: Is there any pattern for handling network error when sending requests? VIEW POST

FULL DISCUSSION
 

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

 

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.

 

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)

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!

code of conduct - report abuse