Specifically regarding the situation when a subscription needs to be refreshed, especially if its for no other reason than that the user has been subscribed for a long time and the subscription is going to expire, I'm worried about failures interrupting service for long term users that depend on the notifications.
Currently, it looks like developers are going to have to catch expiring subscriptions in pushsubscriptionchange, and then resubscribe and give the new subscription information to the server. But this is going to be really error prone: what if theres a network error when pushsubscriptionchange gets called? Every developer that wanted to ensure their service was reliable could put in code to catch that and then retry, and also to restart the retrying process in case the browser gets restarted, but that seems like a lot of people repeating the same work, and probably getting it wrong half the time. The result would be a poorer end-user experience and developer frustration.
I think a much better approach would be to let developers specify a webhook in the ServiceWorker that gets called on re-subscription events / a bit before a subscription is going to expire. Then in this case the browser would take care of resubscribing if possible, and then trying to give the new information to the server, retrying with exponential backoff for a few days before giving up, and also being sure to keep retrying even in the case the browser is shut down and restarted, or any other edge case I'm not aware of. In the case of expiring subscriptions, hopefully both the old and new subscriptions would remain valid until the webhook returned a 200 response, so we are sure the server has the new information and there will be no disruption in service. That would make dealing with re-subscribing super simple from the developers end, instead of the daunting, error prone task it would be under the current spec...
Specifically regarding the situation when a subscription needs to be refreshed, especially if its for no other reason than that the user has been subscribed for a long time and the subscription is going to expire, I'm worried about failures interrupting service for long term users that depend on the notifications.
Currently, it looks like developers are going to have to catch expiring subscriptions in
pushsubscriptionchange
, and then resubscribe and give the new subscription information to the server. But this is going to be really error prone: what if theres a network error whenpushsubscriptionchange
gets called? Every developer that wanted to ensure their service was reliable could put in code to catch that and then retry, and also to restart the retrying process in case the browser gets restarted, but that seems like a lot of people repeating the same work, and probably getting it wrong half the time. The result would be a poorer end-user experience and developer frustration.I think a much better approach would be to let developers specify a webhook in the ServiceWorker that gets called on re-subscription events / a bit before a subscription is going to expire. Then in this case the browser would take care of resubscribing if possible, and then trying to give the new information to the server, retrying with exponential backoff for a few days before giving up, and also being sure to keep retrying even in the case the browser is shut down and restarted, or any other edge case I'm not aware of. In the case of expiring subscriptions, hopefully both the old and new subscriptions would remain valid until the webhook returned a 200 response, so we are sure the server has the new information and there will be no disruption in service. That would make dealing with re-subscribing super simple from the developers end, instead of the daunting, error prone task it would be under the current spec...