Service Workers: Cómo realizar un ataque de intermediario en tu propio sitio por diversión y beneficio

Todo este JavaScript también tiene grandes implicaciones en el rendimiento. El ancho de banda ha aumentado mucho en los últimos cinco años. En promedio, es aproximadamente tres veces más rápido tanto en dispositivos móviles como en computadoras de escritorio que en 2017. Pero debido a que los sitios web también se han vuelto más grandes y porque gran parte del front-end se renderiza en el navegador con JavaScript ahora, la web en realidad no es significativamente más rápida que hace cinco años. Y el problema con los promedios es que algunos países tienen internet que en realidad es hasta seis veces más rápido que hace cinco años, pero muchos países siguen luchando con velocidades de escritorio más lentas que la velocidad promedio de los dispositivos móviles hace cinco años. El ancho de banda no está distribuido de manera uniforme y, como suele ser el caso, las personas que viven en la pobreza tienden a sufrir más.

Entonces, de lo que quiero hablar hoy son los Service Workers. Una herramienta relativamente nueva en nuestro conjunto de herramientas que podemos usar para brindar más resiliencia en las cosas que construimos. Los Service Workers pueden hacer que nuestros sitios sean más rápidos y permitirnos construir sitios web y aplicaciones que sigan funcionando incluso cuando las cosas salen mal.

Hola, soy Chris Ferdinandi, esta es mi cara. Puedes encontrarme en línea en gomakethings.com. En Internet soy conocido como el chico de Vanilla JS. Enseño a las personas JavaScript e irónicamente, paso mucho tiempo diciéndoles a las personas cómo usar menos en las cosas que construimos. Escribo un boletín diario gratuito y creo cursos y dirijo talleres y puedes encontrar más información sobre todo eso en gomakethings.com.

Aquí está la agenda para la charla de hoy. Pasaremos mucho tiempo hablando sobre qué son los Service Workers y cómo funcionan y luego profundizaremos en algunas estrategias específicas que puedes usar al implementarlos. Finalmente, echaremos un vistazo a algunas cosas geniales que puedes hacer con ellos. Siempre encuentro que mirar ejemplos tangibles específicos ayuda a que esto se entienda. Vamos a ver código, pero solo nos quedan unos 18 minutos y fácilmente se puede llenar una charla de una hora solo con ejemplos de código, así que nos centraremos en algunos ejemplos de alto nivel.

Entonces, ¿qué es un Service Worker? Cada vez que un navegador accede a un sitio web o una aplicación web que has construido, se conecta a la red y obtiene un montón de activos. HTML, CSS, JavaScript, imágenes, fuentes. Un Service Worker es un archivo JavaScript que tu sitio web instala en el navegador y se encuentra entre el navegador y la red. Y para hacer eso, donde normalmente cargarías el resto de tu JavaScript, escribes un poco de JS. Verificas si existe el objeto navigator y si tiene la propiedad service worker, porque los navegadores antiguos no admiten esto. Y si lo tiene, puedes usar el método register para registrar un Service Worker, que es simplemente un archivo JavaScript. Y luego en segundo plano, el navegador descargará ese archivo de forma asíncrona. Y la próxima vez que un usuario visite tu sitio web, lo instalará y lo activará. Y una vez que lo hace, tu Service Worker intercepta todas las solicitudes que salen a la red y todas las respuestas que regresan de ella. Y como un Service Worker es un archivo JavaScript, podemos hacer eso con un escuchador de eventos fetch, simplemente usando el método addEventListener. Y podemos hacer cosas con esas solicitudes y respuestas.

Lo que hace que los Service Workers sean realmente poderosos es que tienen un mecanismo de almacenamiento incorporado. Tienen una caché y pueden contener muchas cosas, mucho más que el almacenamiento local o las cookies. Y en realidad puedes tomar esas respuestas que regresan, guardar copias de ellas en tu caché. Y si algo sale mal con la red, puedes cargar activos desde tu caché guardada localmente en lugar de la red, o eliminarla por completo si quieres. Un Service Worker es un ataque de hombre en el medio en tu propio sitio web, pero uno bueno. Obviamente, hay mucho potencial para abusar de algo así. Por lo tanto, los Service Workers requieren cifrado del navegador y un certificado SSL para funcionar. Existe una excepción para los sitios alojados localmente. Entonces, si solo lo estás ejecutando en tu computadora portátil para probarlo, no necesitas un certificado para eso.

Pero tan pronto como se publique en la web y lo visites con una URL, necesitarás instalar un certificado SSL o el service worker no funcionará.

Echemos un vistazo a algunas estrategias de service worker. Hay dos enfoques básicos que puedes utilizar, network first y offline first. Con el enfoque network first, verificas inicialmente la red para ver si hay alguna respuesta. Y si recibes una respuesta, la pasas al navegador, probablemente guardando una copia en tu caché. Si por alguna razón algo sale mal y no puede encontrar ese recurso o tu sitio se desconecta, puedes verificar la caché, tu almacenamiento local, para ver si tienes una versión guardada de esa solicitud. Y si la tienes, puedes enviarla en su lugar.

Y así es como se ve el código para eso. Vas a usar el método respondWith en el evento de solicitud. Y para este enfoque, en realidad usas un método fetch de JavaScript puro para tomar esa solicitud y hacer otra llamada con esa solicitud. Cuando recibes una respuesta, puedes usar el método clone en la respuesta para hacer una copia y guardarla en tu caché. Luego puedes devolver la respuesta al navegador. Y si algo sale mal dentro del evento catch en el método fetch, puedes verificar la caché para ver si tienes una copia de esa solicitud ya almacenada. Y si la tienes, puedes enviar la respuesta asociada con ella. Es realmente muy útil. Network first funciona mejor para activos actualizados con frecuencia. Entonces, documentos HTML, si tienes APIs que llamas con frecuencia y siempre quieres obtener los datos más recientes, probablemente quieras confiar en el enfoque network first para esos también. Offline first funciona de manera similar, pero simplemente invierte el orden. Entonces, cuando recibes una solicitud, lo primero que haces es verificar tu caché local para ver si tienes una versión de esa solicitud ya guardada. Y si la tienes, la usas. Si no la tienes, entonces recurres a la red y guardas una copia en tu caché antes de enviarla de vuelta al navegador.

Y así es como se ve el código para eso. Una vez más, estamos usando el método respondWith para enviar una respuesta para esa solicitud, pero esta vez estamos verificando primero la caché de la aplicación para ver si hay algo almacenado allí que coincida con la solicitud. Si lo hay, lo enviamos de vuelta, pero si no, usamos nuevamente el método fetch para hacer una llamada en vivo a la red para esa respuesta o para esa solicitud más bien. Y cuando la recibimos, podemos clonarla, guardarla en nuestra caché y luego devolver la respuesta.

Offline first es mejor para activos estáticos que no cambian tanto. Entonces, CSS, JavaScript, imágenes, fuentes. También puedes usar service workers para proporcionar alternativas cuando ocurren problemas. Y esto funciona tanto para el enfoque network first como para el enfoque offline first. Con el enfoque network first, haces una llamada a la red.

Si no obtienes ninguna respuesta, verificas la caché. Y si aún no encuentras nada, puedes devolver un recurso diferente. Esto podría ser algo que descargaste cuando tu service worker se instaló por primera vez. Puedes almacenar en caché de manera preventiva algunos recursos de respaldo para cuando las cosas salgan mal, o puedes hacer una llamada en vivo a la red en tiempo real.

Con un enfoque sin conexión primero, haces lo mismo, pero al revés. Verificas tu caché, no encuentras nada, verificas la red, y si aún no encuentras nada o no puedes acceder a la red, entonces envías un recurso de respaldo en su lugar.

Y aquí tienes cómo podría verse el código para eso. Cuando un service worker se instala, en realidad desencadena un evento de instalación dentro del propio archivo del service worker. Por lo tanto, puedes escuchar eso con un event listener. Y cuando eso sucede, puedes abrir una nueva caché y hacer una solicitud a los recursos que deseas guardar con el nuevo constructor de solicitud. Y en este ejemplo aquí, estoy solicitando el documento HTML sin conexión que quiero enviar a las personas cuando no pueden encontrar páginas. Y luego, dentro de mi event listener de fetch, dentro del controlador catch, voy a verificar si esa solicitud está en la caché. Y si por alguna razón no lo está, entonces voy a enviar el documento HTML sin conexión que tengo en caché en su lugar.

Veamos algunos usos y ejemplos de service workers. Aquí es donde creo que las cosas realmente comienzan a encajar. Un ejemplo muy sencillo aquí, es mostrar información crítica cuando un sitio se queda sin conexión. Entonces, si alguien pierde completamente la conectividad, aún puedes brindarle una experiencia utilizable. Y esto es realmente útil para cosas como restaurantes, conferencias y hoteles. Por ejemplo, con un restaurante, puedes informar al usuario que está sin conexión y luego brindarle otras cosas que pueda necesitar o desear de tu restaurante. Número de teléfono, dirección o indicaciones sobre cómo llegar allí. Tal vez un menú abreviado y un número de teléfono para hacer reservas.

Para una conferencia, puedes tener el programa de esa conferencia, el lugar, y el nombre del organizador en caso de que alguien necesite ponerse en contacto con alguien y simplemente no pueda cargar la página web o tenga problemas de conexión, lo cual es bastante común en hoteles y lugares de conferencias donde muchas personas están usando el Wi-Fi y las cosas se rompen o dejan de funcionar. Ampliando esto un poco más, puedes almacenar en caché páginas en tiempo real a medida que las personas las visitan, y luego, si por alguna razón pierden la conexión, puedes mostrarles una lista de las páginas que visitaron y ponerlas a su disposición aunque el sitio esté sin conexión. Y esto es especialmente útil para sitios de referencia, sitios de noticias, redes sociales, aplicaciones de utilidad, porque el hecho de que el sitio esté sin conexión no significa que las personas no puedan seguir usándolo y acceder a cosas a las que ya han ingresado.

Puedes usar service workers para almacenar en caché activos principales por razones de performance. Cosas como CSS, JavaScript, imágenes, fuentes, cualquiera de estos archivos pesados y comúnmente utilizados, puedes guardarlos localmente y luego servirlos desde la red, desde la caché en lugar de ir a la red. Esto también es muy útil para personas que tienen planes de datos limitados o viven en áreas donde descargar cosas lleva mucho tiempo. Esto puede acelerar drásticamente el performance. Una vez que tienes ese activo guardado, puedes servirlo desde tu caché una y otra vez y se mostrará instantáneamente en lugar de tomar unos cientos de milisegundos o varios segundos, dependiendo de la velocidad de conexión de una persona y como ya habrás deducido hasta ahora, puedes utilizar estas diferentes técnicas en conjunto. Por lo tanto, no tienes que elegir solo la opción de sin conexión primero o red primero. Puedes usar esos enfoques diferentes para diferentes tipos de activos. Por ejemplo, para cosas como CSS y JavaScript, puedes ir primero sin conexión para esos y luego puedes usar red primero para tu HTML y solicitudes de API y tenerlos como respaldo cuando las cosas estén sin conexión.

Ahora, en el extremo más extremo de las cosas, puedes ir completamente sin conexión y esto es genial para cosas como aplicaciones y juegos donde una vez que descargas los activos iniciales, el HTML, el CSS y el JavaScript, tienes todo lo que necesitas y nunca necesitas volver a la red. Piensa en una aplicación de utilidad como una calculadora o un juego como un juego de Pac-Man basado en JavaScript. Y si combinas esto con un archivo manifest.json, puedes convertir la simple aplicación web con un service worker en una aplicación web progresiva que los usuarios pueden instalar en su pantalla de inicio y luego cargar completamente sin conexión sin ninguna de las barras del navegador para que funcione como una aplicación nativa, pero es una aplicación web que funciona completamente sin conexión. Ahora, mi uso favorito personal para los service workers es reemplazar aplicaciones de una sola página que tienden a ser muy frágiles y se rompen fácilmente con aplicaciones de varias páginas que son más resistentes y en mi experiencia, realmente brindan una mejor developer experience. Con una aplicación de una sola página, todo el sitio o aplicación existe en un solo archivo HTML. JavaScript renderiza el contenido, maneja el enrutamiento de URL, etc. Ahora, la idea detrás de esto es que como solo se actualiza el contenido y no tienes que volver a descargar todo el JavaScript y CSS, cada página se carga más rápido y si tienes un sitio impulsado por API donde obtienes datos de una solicitud de API y luego los usas para renderizar tu contenido, puedes mantener eso en memoria a medida que las páginas cambian y no tienes que hacer constantemente nuevas llamadas a la API cada vez que se recarga la página, pero como ya hemos aprendido, los service workers pueden brindarte muchos de esos mismos beneficios y el problema con las aplicaciones de una sola página es que rompen muchas cosas que el navegador te brinda de forma gratuita y necesitas recrearlo con JavaScript. Por ejemplo, necesitas interceptar los clics en los enlaces y suprimirlos. También quieres detectar si el usuario hizo clic derecho en el enlace o hizo clic con el botón de comando y está tratando de abrirlo en una nueva pestaña o ventana y permitirles hacerlo. Muchas aplicaciones de una sola página rompen esta experiencia y rompen las expectativas del usuario. Una vez que detectas ese clic, necesitas determinar qué HTML mostrar en función de la ruta de la URL, luego debes actualizar la URL en la barra de direcciones sin provocar una recarga de página porque eso sería contraproducente.

Necesitas manejar los clics en los botones de avance y retroceso, que muchas aplicaciones de una sola página simplemente olvidan. Actualizar el título del documento, cambiar el enfoque o la posición de desplazamiento en el documento dependiendo de dónde se supone que debe estar alguien. Nuevamente, algo que muchas aplicaciones de una sola página rompen. Y luego realmente quieres cambiar el enfoque de vuelta al documento o idealmente al elemento de encabezado para que los usuarios de lectores de pantalla reciban un anuncio que les indique que la página ha cambiado y sepan dónde están. Esto es otra cosa que muchas aplicaciones de una sola página olvidan y rompen, lo que empeora la experiencia para sus usuarios en lugar de mejorarla.

Una de las cosas que a la gente le encanta de las aplicaciones de una sola página es que si la conexión a Internet se interrumpe, aún se puede utilizar la aplicación. Y las cargas de página se sienten instantáneas. Pero cuando se combinan con service workers, las aplicaciones de múltiples páginas te brindan esos mismos beneficios pero con más resistencia y menos complejidad para los desarrolladores que una aplicación de una sola página. Todavía puedes renderizar HTML con JavaScript. Este enfoque es ayudado por los generadores de sitios estáticos que te permiten combinar plantillas y archivos de markdown para pre-renderizar cientos o miles de archivos HTML. Debido a que no requieren renderizado en el servidor, se cargan rápidamente y se pueden almacenar en caché fácilmente con service workers. Y cuando los combinas con CDNs, la experiencia se vuelve aún más rápida.

Ahora, cuando hablo de esto, siempre me preguntan sobre la parte de la API. Entonces, estás haciendo una llamada a una API y con una aplicación de una sola página, eso simplemente vive en la memoria del navegador y nunca tienes que preocuparte por ello nuevamente. Pero con un service worker, aún haces una llamada a la red como lo harías la primera vez porque cargas una aplicación de una sola página y luego almacenas en caché esa respuesta JSON en la caché de tu service worker en lugar de intentar mantenerla en memoria durante toda la sesión. La advertencia aquí es que generalmente quieres establecer una fecha de vencimiento. Entonces quieres que esto desaparezca eventualmente ya sea cuando el usuario cierra sesión o cuando finaliza la sesión o después de un cierto período de tiempo. Y luego, cada solicitud posterior, cada carga de página para esa API, la cargas desde la caché del service worker en lugar de hacer una solicitud a la red. Y esto te brinda efectivamente esa misma respuesta instantánea que obtendrías si simplemente la mantuvieras en la memoria del navegador, pero sin toda esa sobrecarga para los desarrolladores.

Todos los que compran uno de mis cursos o masterclass o eBooks obtienen acceso a un portal donde pueden descargar todo su contenido. Y es una aplicación de múltiples páginas construida de esta manera. El logotipo, el menú de navegación y el encabezado de la página están codificados en el HTML utilizando un generador de sitios estáticos. El contenido varía de un usuario a otro y proviene de una llamada a la API que se carga dinámicamente con JavaScript. He grabado un video de mí navegando por este portal en tiempo real para que puedas ver qué tan rápida es la experiencia. La mayoría de mis estudiantes realmente piensan que es una aplicación de una sola página, pero no lo es. Es una aplicación de múltiples páginas y las páginas se cargan casi instantáneamente porque utilizan HTML renderizado estáticamente y datos de la API que se sirven localmente desde la caché. Por lo tanto, está disponible de inmediato tan pronto como se solicita. Y esto resulta en una experiencia realmente rápida que fue más fácil de construir, más fácil de mantener, y es mucho más resistente que la versión de una sola página de esta aplicación. Y lo sé porque construí ambas versiones y las comparé para ver cuál funcionaba mejor, tanto desde una experiencia ergonómica para mí como desde una perspectiva de resistencia para mis usuarios. Entonces, si solo recuerdas una cosa de esta charla, espero que entiendas que al utilizar Service Workers en lugar de la frágil estructura que tenemos hoy, podemos construir una web más rápida y resistente que funcione mejor para todos.

Si encontraste esta charla interesante, he reunido un montón de recursos para ti sobre Service Workers en gomakethings.com.js Nation. Puedes encontrar las diapositivas de esta charla así como una gran cantidad de artículos relacionados, podcasts, libros y más. Muchas gracias. Fue realmente genial hablar contigo. ¡Whoop, whoop, whoop, whoop! Esa fue una charla tan buena. Quiero que vayas al canal de la community comunidad y nos envíes tus mejores emojis para felicitar a Chris por una charla tan increíble. De verdad, realmente me encantó escucharla. Y también, una cosa que debemos hacer antes de continuar es descubrir la respuesta a la pregunta que planteó Chris. Chris nos preguntó, ¿tabulaciones o espacios? Y voy a poner la encuesta en este momento y verificar cuál fue la respuesta. Entonces, tabulaciones o espacios, y podemos ver que la mayoría de ustedes personas maravillosas han dicho, veamos, tabulaciones, lo cual es genial. Gracias, tienen la misma mentalidad, son como yo. Legítimamente, estoy tanto contento como sorprendido por esto.

Ahora traigo a Chris, así que estás satisfecho y sorprendido. Entonces, ¿qué eliges normalmente tú mismo? Soy de pestañas, siempre de pestañas. Chris, ya me caes bien, ya me caes bien. Es objetivamente lo mejor, pero- Absolutamente, ¿qué están haciendo las personas con espacios? Es eficiencia, presionarlo una vez en lugar de presionarlo cuatro veces, vamos, estoy bromeando. Soy muy apasionado de mi amor por las pestañas. Todos aquí son desarrolladores.

Pero Chris, muchas gracias por esa charla. Realmente lo apreciamos, y tenemos muchas preguntas que están llegando. Así que asegúrate también si estás escuchando y aún tienes una pregunta que quieres hacer, déjala en el chat, en el canal de preguntas y respuestas, lo siento, ahora mismo y nos aseguraremos de responder a todas ellas. Así que voy a ir directamente a una pregunta que tenemos de Alexius, quien pregunta, ¿puedo interceptar o obtener solicitudes para un punto final de API y agregar o modificar un parámetro de búsqueda de esta solicitud? En cierto modo, sí. Y me reservo el derecho de estar completamente equivocado aquí porque no lo he intentado yo mismo. Es posible que los navegadores presenten algún tipo de security en esto que desconozco, pero la limitación aquí con las solicitudes de API es que con los service workers, solo puedes interceptar solicitudes GET, no POST, PUT, DELETE, nada de eso. Pero utilizando este enfoque, teóricamente podrías obtener la solicitud y luego usar el método fetch en tu service worker para llamar al mismo punto final con un parámetro modificado o un parámetro adicional o algún tipo de variables adicionales agregadas. Y luego, cuando obtengas el resultado, lo pasas. Ni siquiera tienes que almacenar en caché el resultado. Esto podría ser algo que haces en tiempo real como una forma de, como sugiere el título de mi charla, realizar un ataque de intermediario en tu propio sitio. Pero sí, conceptualmente puedes hacer eso absolutamente. No sé si los navegadores podrían, por razones de security, ponerse un poco en alerta sobre la idea de ese tipo de cosas. Pero creo que eso es algo que definitivamente puedes hacer.

Eso es increíble. Eso es increíble. Me encanta cuando hablas de eso como un ataque de intermediario en ti mismo. No sé por qué, simplemente me hace reír. Y tenemos otra pregunta. Y esta también quiero saber la respuesta. CRS 1138 dice que esta es una charla genial, pero ¿tienes un tutorial sobre Service Workers? Sabes mucho y eres muy bueno explicándolo. ¿Verdad? Gran pregunta. Déjame averiguarlo. Suena como algo realmente tonto de decir. Escribo tanto que sí, lo tengo.

Tengo una serie de ellos. Me aseguraré, parece que tengo nueve. Los dejaré en Discord cuando termine esta sesión de preguntas y respuestas, y me aseguraré de responder directamente a tu mensaje para que lo veas. Sí, porque tengo un montón de ellos. También tengo algunos libros recomendados y otras cosas así, que también puedes consultar. Específicamente, 'Going Offline' de Jeremy Keith, es donde aprendí la mayoría de lo que sé sobre service workers. Es un libro increíble que recomiendo mucho. Voy a echarle un vistazo a ese libro. Gracias por la recomendación. Tenemos otra pregunta de Phil Don que dice, ¿se pueden adoptar gradualmente los service workers en una base de código existente, tal vez en función de un punto final a la vez? Absolutamente. Y en una base de código existente, de hecho creo que adoptar gradualmente todas las cosas es probablemente la mejor manera de hacerlo. Es algo realmente agradable donde puedes comenzar agregando solo algunas funcionalidades básicas, y luego puedes hacerlo progresivamente más complejo a medida que el tiempo lo permita. Por ejemplo, creo que una de las cosas más fáciles y de bajo esfuerzo que puedes hacer con los service workers, si no tienes ninguno en tu sitio, es usarlos para almacenar en caché activos de larga duración y acceso frecuente. Archivos CSS, JavaScript, imágenes, cosas así, solo para darle a tu sitio un pequeño impulso de rendimiento. Y luego, a partir de ahí, puedes comenzar a agregar más cosas como almacenar en caché puntos finales, o proporcionar una experiencia de primer plano sin conexión, o incluso una experiencia de respaldo para que las personas puedan acceder a cosas que han visto previamente. Pero puedes agregar eso más adelante después de haber establecido esa experiencia básica. Tiene sentido. Tiene sentido.

Y alguien ha preguntado, hablando de almacenamiento en caché, dicen que el almacenamiento en caché es lo mejor para la mayoría de los casos de uso, sí. Pero ¿puedes ayudarles a entender cómo y cuándo deben invalidarse las cosas? Si hay una nueva versión del sitio, ¿qué tan efectivo sería? ¿Y es fácil de implementar? Sí. Sí, gran pregunta. Realmente no toqué esto en absoluto en la charla debido a las limitaciones de tiempo y todo eso. Los service workers son súper mágicos en el sentido de que cada vez que el navegador carga uno, el propio service worker también se almacena en caché. Pero cada vez que se carga, si hay una conexión a Internet y el navegador puede obtener la versión más reciente del archivo, ni siquiera es necesario que el nombre del archivo haya cambiado. Simplemente encontrará la versión actual del archivo y la comparará con la existente. Y si un solo byte del nuevo archivo es diferente al que tiene en caché, lo reemplazará en segundo plano con el nuevo archivo y lo actualizará automáticamente para el usuario. También hay algunas advertencias aquí, en realidad no usará ese nuevo archivo hasta que el visitante haya cerrado completamente todas las pestañas abiertas con tu sitio o aplicación. Hay algunos trucos que puedes usar para forzarlo a comenzar a usar el nuevo archivo antes de que ocurra ese proceso de instalación.

El código para eso está en uno de los artículos como parte de una serie que escribí. Así que me aseguraré de dejar un enlace a eso en la sección de preguntas y respuestas para que puedas acceder a él, solo porque las URL se vuelven demasiado largas para que las lea en voz alta aquí.

Sabes que eres realmente bueno educando a las personas en Internet cuando respondes una pregunta con 'Tengo un artículo para eso'. Eso es realmente impresionante.

Tenemos otra pregunta de Kev que dice que esta es una gran charla. Y supongo que también puedes usar un service worker para simular una solicitud de API GET. Estoy bastante seguro de que puedes hacer eso, ¿verdad? Oh, esa es una gran pregunta. Sí. Teóricamente, si alguien llama a un punto final que puede o no existir, puedes interceptarlo y luego responder con, como que en realidad no tienes que hacer una llamada en vivo en ningún lugar. Puedes crear una nueva respuesta utilizando el nuevo objeto de respuesta y enviar cualquier dato que desees. Sí, absolutamente. Eso es realmente interesante y no lo había considerado antes. Sí, suena como una forma interesante de usarlo.

Y Tom Rafa también pregunta, ¿hay alguna situación en la que aconsejarías no usar service workers aparte de buscar actualizaciones frecuentes de datos? Esa es una buena pregunta. Donde recomendaría no usar service workers. No, los service workers son para todo. Los service workers son una de las mejores cosas que han sucedido en Internet por una variedad de razones. Creo que hay diferentes casos de uso para los service workers. Y la forma en que lo implementes en una situación particular puede ser diferente a otra. Por ejemplo, almacenar en caché de manera agresiva puede que no siempre sea apropiado para todas las cosas. Pero no puedo pensar en un solo caso de uso en el que un sitio o aplicación no se beneficie al tener algún tipo de service worker, incluso si solo hace un poco de trabajo. Hay un extremo muy radical donde se almacena en caché todo y se va directamente a la caché primero. Y luego está la experiencia más ligera donde se proporcionan algunas alternativas sensatas. Y luego hay una amplia gama de cosas en el medio. Y qué estrategia elijas dependerá en gran medida de lo que haga tu aplicación y cuánto tiempo tenga tu equipo para implementar este enfoque.

Sí, también entiendo eso, donde tienes un equilibrio entre lo ideal que puedes crear y luego cuánto tiempo y recursos tienes para lograrlo. Y cuando hablaste antes del enfoque gradual, poder utilizar tus recursos para implementarlo lentamente, tiene mucho sentido.

Y luego alguien hizo la pregunta, que creo que es bastante interesante, ¿por qué no muchas aplicaciones utilizan service workers y el enfoque de estar sin conexión en el mundo real? ¿Qué crees que está impidiendo que muchos otros sitios web implementen este enfoque? Creo que hay un par de cosas. En primer lugar, no son realmente nuevos.

Son más nuevas que muchas otras cosas que tenemos.

Pero no siento que sean tan conocidas como algunas de las otras tecnologías y soluciones que tenemos.

También siento que durante mucho tiempo, las aplicaciones de una sola página han sido tan populares que es la herramienta que la gente elige para muchas cosas.

Y así, gran parte de lo que hacemos en el front-end, no solo el no uso de service workers, sino también muchas de las elecciones que hacemos, a menudo parecen ser un producto de la inercia del desarrollador en lugar de ser la mejor herramienta para lo que estamos tratando de lograr.

No voy a mentir.

Recuerdo cuando surgieron las aplicaciones de una sola página.

Me encantaron.

Y esta es una pregunta que también tengo para ti, porque hablaste sobre cómo las aplicaciones de una sola página pueden ser malas por diferentes razones.

Pero ¿cuándo dirías que es realmente la forma correcta de hacerlo?

Sí, creo que un ejemplo en el que las aplicaciones de una sola página pueden tener sentido es si tienes algún tipo de aplicación de chat en tiempo real, Twitter parece ser un buen ejemplo aquí, donde tienes muchas cosas diferentes llegando en gran volumen.

Hacer todo eso de forma asíncrona en el navegador, simplemente obteniendo las cosas nuevas, mostrándolas, creando enlaces al tweet con JavaScript.

Eso probablemente sea más eficiente, escalable y sostenible que intentar hacerlo con HTML codificado en el servidor y almacenar en caché todo con service workers.

Creo que aún puedes usar service workers para proporcionar algunos beneficios de rendimiento y un respaldo sin conexión.

Entonces, cualquier persona que haya cargado una aplicación nativa y todas las publicaciones que estabas viendo justo antes de salir se cargan automáticamente allí, eso es algo genial que puedes hacer en una aplicación web con un service worker.

Pero creo que algo como Facebook o Twitter probablemente funcione mejor como aplicaciones de una sola página que como aplicaciones renderizadas en el servidor.

Aunque estamos comenzando a ver algunas herramientas interesantes que mezclan los límites.

Es muy interesante ver cómo las personas usan Internet de diferentes formas, donde al principio todos pensamos que hay una única forma correcta de hacerlo.

Y luego comenzamos a darnos cuenta de que diferentes enfoques se adaptan realmente a diferentes casos de uso.

Tenemos muchas más preguntas. A la gente le encanta esta charla. Alguien preguntó, ¿suelen notificar al usuario si se implementa una nueva versión, o simplemente esperan a que el service worker se reinstale en la siguiente sesión? Así que digo esto como alguien que usa service workers de manera muy básica y ligera. Realmente no he encontrado la necesidad de hacer eso. Por lo general, los cambios que hago en mis service workers no son lo suficientemente sustanciales como para requerir que necesites recargar el navegador ahora mismo para que esto funcione. O puedo forzar que funcione en segundo plano. Por lo general, lo que sucede con mis service workers es que simplemente almacenan en caché los recursos a medida que llegan. Y puedo hacer una actualización que almacene en caché algunas cosas adicionales o deje de almacenar en caché algunas cosas que estaba almacenando antes. Pero no están haciendo el tipo de trabajo que haría o rompería una aplicación y requeriría mostrar una notificación al usuario. Hay una forma de hacerlo. Usando el método postMessage, puedes enviar eventos a los service workers y luego desde los service workers de vuelta al cliente. Y en ambos archivos, puedes escuchar estos eventos y reaccionar en consecuencia, lo cual es bastante genial. Entonces, si quisieras hacer algo así donde muestres un mensaje en el navegador, eso es absolutamente algo que puedes hacer.

Me encantaría revisarlo. En realidad, nunca había pensado en eso, usarlo de esa manera. Ahora voy a buscarlo en Google y encontrar un artículo tuyo al respecto. Pero muchas gracias, Chris, ha sido un placer hablar contigo y aprender porque eres muy conocedor de los service workers. Pero ya que mencionaste los tutoriales que escribes, ¿dónde podemos encontrar esos tutoriales y dónde podemos obtener más información sobre las cosas de las que escribes? Sí, te recomendaría que si te gustó esto y quieres aprender más, si visitas gomakethings.com/JSNation, he reunido un montón de recursos sobre service workers, artículos recomendados, libros, formularios para suscribirte a mi boletín, así como las diapositivas y el video de esta charla. Así que puedes encontrar todo eso en mi sitio web.

Genial, gracias. Y Amit es muy amable, tenemos beneficios de empresas y patrocinadores pero también tenemos beneficios de los ponentes. Así que definitivamente visita su sitio web y voy a visitarlo justo después de este evento. Estoy muy emocionado, pero muchas gracias Chris por estar aquí. Espero que lo hayas disfrutado. Yo sí, ha sido genial. Voy a ir a Spatial si alguien quiere charlar. Genial, sí, únete a Chris en el chat de Spatial. El enlace estará en la línea de tiempo a continuación. Nos vemos allí, Chris. ¡Salud! ♪♪