Service workers y la API de Cache Storage

Jeff Posnick

Te enfrentas a una lucha por la confiabilidad de la red. La caché HTTP del navegador es tu primera línea de defensa, pero, como aprendiste, solo es realmente eficaz cuando se cargan URLs con versión que ya visitaste. Por sí sola, la caché HTTP no es suficiente.

Por suerte, hay dos herramientas más nuevas disponibles para ayudarte a cambiar la situación a tu favor: los trabajadores en primer plano y la API de Cache Storage. Dado que se usan con frecuencia en conjunto, vale la pena aprender sobre ambos al mismo tiempo.

Service workers

Un service worker está integrado en el navegador y se controla con un poco de código JavaScript adicional que debes crear. Lo implementas junto con los otros archivos que conforman tu aplicación web real.

Un servicio trabajador tiene algunos poderes especiales. Entre otras tareas, espera pacientemente que tu app web realice una solicitud saliente y, luego, la intercepta para comenzar a actuar. Depende de ti lo que haga el service worker con esta solicitud interceptada.

Para algunas solicitudes, la mejor opción podría ser permitir que la solicitud continúe en la red, como sucedería si no hubiera un trabajador de servicio.

Sin embargo, para otras solicitudes, puedes aprovechar algo más flexible que la caché HTTP del navegador y mostrar una respuesta rápida y confiable sin tener que preocuparte por la red. Eso implica usar la otra pieza del rompecabezas: la API de Cache Storage.

La API de Cache Storage

La API de Cache Storage abre un nuevo abanico de posibilidades, ya que les brinda a los desarrolladores un control total sobre el contenido de la caché. En lugar de depender de una combinación de encabezados HTTP y las heurísticas integradas del navegador, la API de Cache Storage expone un enfoque de almacenamiento en caché basado en código. La API de Cache Storage es particularmente útil cuando se llama desde el código JavaScript de tu trabajador de servicio.

Espera… ¿hay otra caché en la que pensar ahora?

Es probable que te preguntes lo siguiente: "¿Debo configurar mis encabezados HTTP?" y "¿Qué puedo hacer con esta nueva caché que no era posible con la caché HTTP?". No te preocupes, esas son reacciones naturales.

De todas formas, te recomendamos que configures los encabezados Cache-Control en tu servidor web, incluso si sabes que estás usando la API de Cache Storage. Por lo general, puedes configurar Cache-Control: no-cache para las URLs sin versión o Cache-Control: max-age=31536000 para las URLs que contienen información de control de versiones, como hashes.

Cuando se propaga la caché de la API de Cache Storage, el navegador comprueba de forma predeterminada si hay entradas existentes en la caché de HTTP y las usa si las encuentra. Si agregas URLs con versión a la caché de la API de Cache Storage, el navegador evita una solicitud de red adicional. El lado negativo de esto es que, si usas encabezados Cache-Control mal configurados, como especificar una vida útil de caché de larga duración para una URL sin versión, puedes agravar la situación si agregas ese contenido inactivo a la API de Cache Storage. Ordenar el comportamiento de la caché HTTP es un requisito previo para usar de manera eficaz la API de Cache Storage.

En cuanto a lo que ahora es posible con esta nueva API, la respuesta es: mucho. Estos son algunos usos comunes que serían difíciles o imposibles con solo la caché HTTP:

• Usa un enfoque de "actualización en segundo plano" para el contenido almacenado en caché, conocido como inactivo durante la validación.
• Imponer un límite a la cantidad máxima de recursos que se almacenarán en caché e implementar una política de vencimiento personalizada para quitar elementos una vez que se alcance ese límite
• Compara las respuestas de red almacenadas en caché y las nuevas para ver si cambió algo y permite que el usuario actualice el contenido (con un botón, por ejemplo) cuando los datos se hayan actualizado.

Consulta La API de Cache: Una guía rápida para obtener más información.

Aspectos básicos de la API

Hay algunos aspectos que debes tener en cuenta sobre el diseño de la API:

• Los objetos Request se usan como claves únicas cuando se lee y escribe en estas cachés. Para tu comodidad, puedes pasar una cadena de URL como 'https://example.com/index.html' como clave en lugar de un objeto Request real, y la API se encargará de eso automáticamente.
• Los objetos Response se usan como valores en estas cachés.
• El encabezado Cache-Control en un Response determinado se ignora de manera efectiva cuando se almacenan datos en caché. No hay verificaciones de vencimiento ni actualización automáticas integradas, y una vez que almacenes un elemento en la caché, este persistirá hasta que tu código lo quite de forma explícita. (Existen bibliotecas para simplificar el mantenimiento de la caché en tu nombre. Se analizarán más adelante en esta serie).
• A diferencia de las APIs síncronas anteriores, como LocalStorage, todas las operaciones de la API de Cache Storage son asíncronas.

Un desvío rápido: promesas y async/await

Los trabajadores del servicio y la API de Cache Storage usan conceptos de programación asíncrona. En particular, dependen en gran medida de promesas para representar el resultado futuro de las operaciones asíncronas. Antes de comenzar, debes familiarizarte con las promesas y la sintaxis relacionada async/await.

No implementes ese código… todavía

Si bien proporcionan una base importante y se pueden usar tal como están, tanto los trabajadores de servicio como la API de Cache Storage son, en realidad, componentes básicos de bajo nivel, con una serie de casos extremos y "trampas". Hay algunas herramientas de nivel superior que pueden ayudar a suavizar las partes difíciles de esas APIs y proporcionar todo lo que necesitas para compilar un trabajador de servicio listo para producción. En la siguiente guía, se explica una de esas herramientas: Workbox.