Estoy creando un pwa para un cliente que enumerará las próximas tareas para sus empleados. A menudo estarán en áreas con un servicio móvil deficiente, por lo que la intención es que los registros se descarguen siempre que tengan datos y luego se carguen localmente desde indexeddb.
Mi intención original era usar "sincronización periódica" hasta que me di cuenta de que el tiempo máximo de actualización era una vez cada 12 horas.
A continuación, pasé a la sincronización en segundo plano regular, con la aplicación js enviando una solicitud de sincronización al trabajador del servicio y el trabajador del servicio ejecutando la funcionalidad en ExtendableEvent.waitUntil como en el ejemplo de sincronización en segundo plano de Google:
self.addEventListener('sync', function(event) { if (event.tag == 'myFirstSync') { event.waitUntil(doSomeStuff()); } }); Sin embargo, lo que encontré es que event.waitUntil solo parece volver a intentar la llamada cada 5 minutos y quiero una frecuencia de actualización mucho más rápida (más como cada 30 segundos).
Tengo 2 preguntas: primero, ¿es posible acelerar la tasa de reintento en waitUntil ?
Quizás lo más importante, ¿es esta una estrategia útil? Me parece que mi aplicación podría llamar repetidamente a la función de actualización sin siquiera molestar al trabajador del servicio. ¿Qué ventaja obtengo realmente de la sincronización en segundo plano?
¿Hay algo más en el conjunto de herramientas de pwa que se adapte mejor a mis necesidades?
El beneficio de la sincronización en segundo plano (regular, "no periódica") es que la duración de los reintentos se extiende más allá de la duración de la aplicación web abierta. Una vez que la sincronización finalmente tenga éxito, puede hacer algo como mostrar una notificación (suponiendo que el usuario haya otorgado permiso) que lo llevará de regreso a su aplicación web para continuar trabajando.
Debido a que esta función implica la ejecución de código en segundo plano, con el navegador abierto pero la aplicación web potencialmente cerrada, existen límites impuestos por el navegador sobre la frecuencia con la que se ejecutará el código. No puede aumentar la frecuencia de los reintentos.
Pero definitivamente puede implementar la lógica de reintento fuera del contexto del trabajador del servicio y la sincronización en segundo plano, ejecutando el código con la frecuencia que desee desde el contexto de su propia aplicación web. Pero en ese escenario, los reintentos cesarán tan pronto como el usuario cierre su aplicación web.