A finales de la semana pasada varios medios se hicieron eco de una de las futuras implementaciones que Chrome y Firefox llevan desarrollando desde hace al menos (de forma pública) un año.
La razón, según parece, fue una de las charlas recientes de Alex Russell sobre Service Workers, que ni fue la primera ni fue la más importante (mismamente en el último Google I/O dio otra casi igual (EN)).
El porqué me veo forzado a escribir sobre ello es debido a que duele ver que medios especializados recurran a titulares de la talla de: El fin del error 404, ¿Adios al error 404?, Google termina con los errores 404,… haciendo entender que este nuevo servicio (aún en fase alpha) es el perfect killer de uno de los principales problemas de la arquitectura web cliente/servidor.
Índice de contenido
Desmitificando el mito
La idea detrás de Service Workers no es nueva. Básicamente hablamos de un proxy como el que vemos en muchas de las redes WIFIs de hoteles, en páginas de universidades e incluso en servicios CDN como Cloudflare (que un servidor tiene implantado en esta misma web), que hacen un MITM legítimo para forzar alguna funcionalidad en el cliente.
El objetivo, eso sí, y obviando todos los peligros y problemas asociados a su masiva implantación, sería que cada web pudiera desarrollar una versión más o menos restringida de su contenido para ser navegable offline, si de antemano el usuario ha entrado en la misma, tirando de una combinación de webcaché con funciones vitaminadas.
Es decir, evitar así que si falla la conexión, la experiencia de navegación por internet se corte, cosa que ocurre actualmente con las versiones web de páginas, y que no tiene porqué ocurrir con las aplicaciones.
Pero claro, esto, como decía obviando algunos puntos.
Seguridad
En ese hipotético futuro en el que internet pueda ser navegable (aunque limitadamente) de forma offline, habría que considerar el riesgo de que toda esa caché con capacidad de precargar scripts funcionales pueda ser corrompida. Y me refiero a que cualquier vulnerabilidad que afectara al navegador, o permitiera la escalada de privilegios necesaria para modificar los archivos cacheados, podría permitir a un atacante suplantar la comunicación y mostrar contenido offline que viene con “regalito”, así como robar credenciales de acceso y en definitiva cualquier técnica aplicable a un man in the middle o un man in the browser.
Habría que ver también la capacidad de ese proxy para forzar o modificar la conexión una vez el dispositivo tenga nuevamente acceso a la red. Precisamente la webcaché, tal y como funciona actualmente, evita eso ya que no es operativa (no permite realizar acciones funcionales más que la propia navegación por las páginas precargadas). Al incluirle capacidades operativas, podría (quizás) forzar a un cliente con página precargada a realizar la conexión a otro servidor, o directamente mantenerle un tiempo indeterminado en los dominios locales, pese a que ya tenga acceso a la red.
Almacenamiento limitado
Y lo señalo como un punto trascendental para su paulatina adopción, puesto que los dispositivos que más necesitan esta funcionalidad son los dispositivos móviles (smartphones, tablets y wearables, por ahora), y son precisamente estos los que mayor problema de espacio disponible tienen.
Mantener una webcaché funcional ocupará bastante, más si todas las webs hacen acopio de esta funcionalidad. Eso afectará directamente no solo al espacio disponible, sino al gasto de conexión (junto con la carga de la web, deberemos descargar una versión empaquetada de la misma, y previsiblemente, archivos externos necesarios para su funcionamiento offline).
Así que prepárese para destinar un porcentaje más que significativo del almacenamiento a páginas web cacheadas y a aumentar la tarifa de datos, porque lo va a necesitar (aunque no haga uso de ello).
No todo es malo
Y esto hay que dejarlo bien claro. Escribo el artículo como respuesta a la infoxicación que he estado observando estos días, señalando la parte negativa del mismo, pero no me gustaría que pensase que estamos ante algo que traerá más problemas que ventajas.
Service Workers es justo lo que la web necesita. Los errores 404 son un lastre para la experiencia de navegación, y una de las principales ventajas del mundo app frente al web.
No tiene sentido que en un entorno cargado de las virtudes de lenguajes de programación funcionales en el cliente, sigamos apostando por una arquitectura cliente/servidor tradicional. No lo hacemos de forma online, y por tanto, no tendría sentido seguir haciéndolo offline.
Ahora bien, hay que señalar lo bueno y lo malo. Que Service Workers (o los que vengan) es un paso necesario para la evolución de la web es un hecho, pero sin olvidar que entraña unos riesgos que deberían ser controlados.
Apostar por una sandbox que limite el ámbito de las webs cacheadas, que controle peticiones externas, modificaciones y tiempo de vida de los archivos, podría ser una estrategia de éxito que espero tomen.
Por ahora, todo son cabilaciones. Se habla que hasta finales del año que viene no veremos versiones estables de Service Workers, y entonces habrá que decidir si apostamos por ello (con el gasto de desarrollo que conlleva) o si quedará como un camino fallido más en el cauce de evolución de los navegadores.
Y yo me pregunto,
– ¿la llamada “experiencia de navegación” ha de ser un producto edulcorado para que nadie se sienta frustrado?
– ¿hasta que punto?
– ¿No es más interesante educar a los hacedores de páginas y sitios web, para que no exista el 404, ni 403, ni 500, ni …?
– ¿no resulta mejor decir de una vez que los sitios web perfectos son una quimera y, al igual que estas, no existen?
Hombre, una cosa es un error 404 que te tire el propio navegador (con la pérdida de experiencia de usuario esperable), y otra es el control interno de un 404, con su cajón de búsqueda y en el mismo entorno.
Pero todo esto se hace de forma online. El problema viene cuando estamos offline, sin línea. Ahí, por mucho que el desarrollador haya aplicado una gestión efectiva de los errores, poco se puede hacer.
Es ahí donde entraría un proxy local como el que ofrecerá Service Workers: mantener una experiencia aceptable (restringida, está claro) para microcaídas o esos viajes en transporte público. Para largos periodos, seguramente ni esto servirá, como no sirve hoy en día una app que tira de contenido en la nube.