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?
Top comments (4)
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.
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.
As cache in this context you mean persist them in the local storage or the service worker cache?
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/...):
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.
Isn't that what the service worker does? Using the cache API
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!