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!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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!