Más información sobre el Declarative Web Push

Me llamo Brady Eidson y soy ingeniero del equipo de WebKit Architecture. Te contaré sobre los últimos avances en notificaciones push web.

Las notificaciones push son una parte crucial de la web y de cualquier plataforma moderna.

En 2009, con iPhone OS 3, incorporamos las notificaciones push a las plataformas de Apple. Fuimos los pioneros, pero las notificaciones push pertenecían a todas las plataformas modernas. Se agregaron a macOS, otras plataformas de escritorio y otras móviles poco después. Las apps podían asumir que las notificaciones push estaban integradas en la plataforma.

Al inicio, ajustábamos el funcionamiento del push en las apps nativas para encontrar el punto óptimo para desarrolladores y usuarios. Siempre supimos que las notificaciones push pertenecían a la web y queríamos ser intencionales en los detalles. Agregamos notificaciones push de Safari a Safari 7. Los desarrolladores adoptaron Safari Push y los usuarios participaron, así que íbamos por el camino correcto. Safari Push requería una integración con los sistemas de Apple y no se pudo estandarizar para que otros navegadores lo implementaran. Todos los navegadores necesitaban notificaciones push. La comunidad de estándares web trabajó en Web Push y el primer navegador lo lanzó un año o dos después.

En estándares web, fue una era de gran atención a las funciones de JavaScript. Web Push original se diseñó para ser un sistema flexible, 100% impulsado en el código JavaScript que escribes. Es un orgullo aprovechar al máximo el rendimiento de JavaScript, pero, como todo ingeniero de software sabe, escribir y mantener código es más propenso a errores que no escribir nada.

Incluso cuando se ejecuta en un motor JavaScript avanzado, la ejecución de cualquier código es menos eficiente que no hacer nada.

Otra desventaja de este enfoque es la privacidad. Los datos del sitio web sirven para rastrear a los usuarios cuando navegan, por lo que la prevención de rastreo inteligente limita la vida útil del JavaScript necesario para el Web Push original.

Con las notificaciones push de iOS, macOS y Safari, el mensaje contiene una descripción estándar de la notificación visible para el usuario. No se debe desarrollar ni ejecutar ningún código específico de la app para mostrarlo.

Las apps nativas no necesitan el código en el dispositivo para mostrar una notificación push. Las apps que iOS descargó muestran sus notificaciones sin problemas.

Al agregar Web Push original a nuestros navegadores, observamos algo interesante. Incluso con la flexibilidad que ofrecen los estándares, muchos sitios web envían mensajes push en JSON fácil de analizar y su JavaScript de Service Worker solo lo traduce a la ejecución API para mostrar la notificación. Gracias a nuestra experiencia con las notificaciones push de iOS, macOS y Safari, tenía sentido. Y nos dio una idea bastante sencilla. Si declarar la notificación de antemano en JSON es un caso común, podemos evolucionar Web Push para que se adapte a tus necesidades.

Al eliminar el paso que requiere escribir código, obtienes los mismos beneficios que las apps nativas disfrutaron desde el principio.

Web Push declarativo ofrece facilidad de uso, eficiencia y transparencia. Usarlo es tan sencillo como enviar los mensajes push en un formato estándar y no requiere mucho código para configurarlo.

Lo diseñamos con la web abierta en mente y colaboramos con la comunidad de estándares. También es compatible con versiones anteriores de navegadores que aún no lo admiten. Web Push declarativo es una mejora progresiva de verdad para la web. Si ya tienes experiencia con el Web Push original, los conceptos que conoces aún se aplican.

Como se basa en estándares establecidos, explicaré las novedades del Web Push declarativo y repasaré las partes del Web Push original. Comencemos con una descripción general de alto nivel del Web Push original.

Depende casi por completo de JavaScript en forma de un Service Worker instalado. Un Service Worker contiene el código de los eventos “push” para mostrar notificaciones.

Luego, necesitas una suscripción push. Contiene información que tu servidor necesita para llegar al navegador del usuario, como la URL para enviar un mensaje push. En respuesta a un gesto del usuario, tu JavaScript solicita una suscripción push y la envía a tu servidor para después.

A la hora de enviar una notificación, se usa la URL de la suscripción para enviar un mensaje push. En los navegadores WebKit, envías el mismo Apple Push Notification Service que usan las apps nativas, pero no necesitas una cuenta de Apple Developer para usar estas suscripciones.

El mensaje llega al navegador, que busca el Service Worker responsable y lo inicia. El navegador envía un evento push a ese Service Worker, que incluye todos los datos que enviaste en tu mensaje push.

El Service Worker analiza el mensaje y construye una ejecución de JavaScript a la API showNotification, que muestra la notificación.

Más tarde, cuando el usuario toca o hace clic en esa notificación, el navegador vuelve a iniciar el Service Worker apropiado si ya no está en ejecución y le envía un evento notificationclick. Tu controlador tiene la tarea de hacer algo útil, que casi siempre es abrir una ventana a una URL.

Así funciona actualmente el Web Push original. La mayoría de los pasos descritos se ejecutan con el JavaScript que debes escribir y que el navegador debe ejecutar.

Si bien el Web Push declarativo no elimina por completo JavaScript, se acerca bastante. El único JavaScript que necesitas con Web Push declarativo es para obtener la suscripción push, ya no necesitas Service Worker.

Cuando envías un mensaje push declarativo, el navegador lo recibe como antes y lo analiza en busca de JSON válido.

Se asegura de que el JSON describa una notificación visible válida para el usuario y la muestra automáticamente.

También sabe cómo gestionar automáticamente los toques o clics en la notificación. Pronto veremos cómo el navegador sabe qué hacer, pero primero veamos el JavaScript necesario para la suscripción push. Analicemos cómo se veía ese código antes con Web Push original y cómo se ve ahora con Web Push declarativo.

Esto les resultará familiar a quienes hayan usado antes el Web Push original.

Como mencioné, el Web Push original requiere un Service Worker instalado antes de continuar. Cuando tengas tu registro de Service Worker, puedes acceder al objeto PushManager en respuesta a un gesto del usuario para pedir una suscripción push.

El código para obtener una suscripción push con Web Push declarativo es similar al anterior, pero como no se requieren Service Workers, PushManager está ahora disponible en el objeto ventana.

Y aquí está la magia. Si usas Web Push declarativo puro, ese es todo el código que tienes que escribir. El Web Push declarativo define un formato JSON estándar para mensajes push. Veamos este mensaje mínimamente válido de la herramienta de infraestructura crítica del equipo, la app web Browser Pets.

Incluye una entrada obligatoria que describe una notificación visible para el usuario.

Esa notificación debe tener el texto del título y una URL a la que navegar si el usuario toca o hace clic en la notificación.

Pero la entrada superior es este valor mágico para un mensaje push declarativo. Siempre debes tener una clave web_push con el valor 8-0-3-0.

8030 es el estándar RFC original del Internet Engineering Task Force para mensajes push web y pensamos que es muy improbable que alguien lo incluya.

Recuerda que antes hablamos del flujo de un mensaje push declarativo a través del navegador.

Buscar la clave mágica es parte de ese flujo.

¿Qué ocurre si el navegador intenta analizar JSON desde el mensaje push y falla? Se recurre al Web Push original y se usa un Service Worker para gestionar el mensaje.

También recurre al Web Push original si el JSON no tiene la clave mágica.

¿Qué ocurre si el mensaje push contiene JSON y tiene la clave mágica, pero no describe una notificación válida?

En ese caso, el navegador simplemente no hace nada y descarta el mensaje. Si un mensaje push pasa todas las comprobaciones, el navegador muestra la notificación automáticamente.

Un título de notificación y una URL de navegación son los requisitos mínimos para una notificación válida. Pero si tienes experiencia con Web Push original, sabrás que JavaScript tiene muchas más opciones al crear una notificación. El Web Push declarativo los admite todos.

Se indica el cuerpo del mensaje y la etiqueta de notificación, y la plataforma debe emitir el sonido de notificación por defecto, si es posible. Estos son solo ejemplos, todo lo que admita el diccionario estándar NotificationOptions del W3C se respeta aquí.

Hay más. Las insignias, que indican el número de no leídos, suelen acompañar a las notificaciones, así que los mensajes push declarativos admiten la actualización integrada de la insignia de la app.

Es un respiro la cantidad de notificaciones que puede mostrar ahora el navegador de forma automática. Pero a veces tus necesidades son más específicas y no puedes confiar completamente en el navegador.

Lo aprendimos con el push nativo en iOS y macOS, y las apps que usan la estructura UserNotifications tienen esta capacidad desde hace un tiempo. Si bien los mensajes push siempre describen una notificación visible, la app puede elegir refinarla y convertirla en algo más útil.

También es compatible con el Web Push declarativo, como procesamiento opcional de un Service Worker. ¿Por qué esto es tan importante? Es útil cuando tienes estándares extremadamente altos para la precisión de tus notificaciones. Por ejemplo, el servidor de Browser Pets podría notificar a un usuario que tiene siete mensajes sin leer, sin saber que el usuario ya leyó tres de ellos. JavaScript en el dispositivo del cliente puede actualizar la notificación para ayudar al usuario.

A veces matemáticamente no es posible incluir el texto de notificación. Los usuarios de Browser Pets esperan encriptación de extremo a extremo excepcional cuando se envían mensajes directos y solo una clave en el dispositivo del cliente permite desencriptar la notificación. Veamos cómo luce. Así es como se ve el JSON de notificación para un mensaje directo típico de Browser Pets.

El JSON contiene los datos que se encriptaron en el dispositivo del remitente. La clave para desencriptar los datos está en el dispositivo del usuario y puede acceder con su Service Worker opcional.

El JSON también incluye una entrada que indica que “mutable” es verdadero. En general, los mensajes se gestionan automáticamente, pero esta entrada indica al navegador que esta notificación debe ser procesada por Service Worker.

Este es el JavaScript que usa Browser Pets para desencriptar mensajes directos.

Le dimos al Service Worker un controlador de eventos push, tal y como lo harías con el Web Push original.

Una novedad es que si el evento enviado se origina en un push especificado como mutable, ahora el evento tiene una copia de la notificación propuesta por el JSON declarativo.

Al inspeccionar esa notificación sabemos que se trata de un mensaje directo y podemos acceder a los datos encriptados.

¿Recuerdas el diagrama de flujo para el Web Push declarativo? Después de validar la descripción de la notificación, el navegador busca la entrada “mutable”.

Si falta o es falso, el navegador muestra la notificación automáticamente.

Si es verdadero y el Service Worker muestra una notificación de reemplazo, el navegador usa el reemplazo en lugar del texto simple del mensaje push.

Entonces, si el Service Worker desencripta correctamente el mensaje directo y reemplaza la notificación propuesta, el navegador mostrará este mensaje desencriptado.

Pero si no logra desencriptar el mensaje y, por lo tanto, no ofrece un reemplazo, se usará en su lugar la notificación de texto simple original.

La notificación declarativa también se usará cuando el Service Worker no pueda iniciarse, quizás porque las funcionalidades de privacidad lo eliminaron o el dispositivo está bajo presión de recursos. La forma en que el Web Push declarativo usa su JavaScript opcional de Service Worker es la misma que como el Web Push original requiere Service Workers. Y eso nos lleva a mi parte favorita. Repasemos la compatibilidad con versiones anteriores.

La mayoría de los navegadores admiten el Web Push original y muchos sitios web ya lo usan. Aunque la adopción masiva del Web Push declarativo sería lo mejor para todos, nos aseguramos de que te sea fácil adoptarlo y que tus notificaciones funcionen en todos los navegadores. Para quienes ya usan Web Push original y realizan un simple análisis JSON para mostrar una notificación, me imagino que el formato ha evolucionado a medida que las necesidades crecían y se hacían más complejas. Así es como Browser Pets evolucionó a lo largo de los años. Cuando el equipo de WebKit logró que funcionara el Web Push declarativo, quisimos que Browser Pets lo usara para enviar las notificaciones más eficientes y fiables posibles. Por supuesto, push debe seguir funcionando en todos los navegadores. Te explicaré cómo lo actualizamos.

Esta notificación JSON de Browser Pets creció orgánicamente con el tiempo.

Antes, solo incluía el texto del título para la notificación.

Al principio, los clics de notificación abrían la app principal Browser Pets, pero luego agregamos la entrada clickURL para configurar dónde podía ir el clic de notificación.

Luego, algunos ingenieros pensaron que la descripción era importante.

El próximo cambio es mi culpa: se me ocurrió que las notificaciones emitieran el sonido de alerta del sistema cuando se pudiera.

Otro ingeniero reconoció que estábamos configurando las notificaciones con un diccionario NotificationOptions estándar de la web y decidió ponerlo explícitamente en el código. Eso sí, no se actualizaron las opciones anteriores.

Este formato JSON ad-hoc tiene los elementos que componen una ejecución API a showNotification, solo que con otros nombres y estructura.

Reorganizarlo para adaptarlo al formato declarativo estándar fue sencillo.

Cambiar el nombre de las propiedades a uno estándar del diccionario NotificationOptions también fue fácil.

Agregamos la clave mágica para indicar al navegador que era un mensaje push declarativo y las notificaciones se automatizaron en los navegadores compatibles más nuevos.

Volviendo a ese JSON ad-hoc. Con el Web Push original, el mensaje push es solo una parte de la historia. Tu Service Worker necesita hacer algo con él. Aquí está el Service Worker original de Browser Pets. Cada argumento del JSON tuvo que ser extraído por su nombre y tuvimos que elaborar un diccionario NotificationOptions para la eventual ejecución a showNotification.

Ahora recuerda cómo se ve el mensaje push declarativo.

Por diseño, el elemento crítico del mensaje declarativo que describe la notificación es a su vez un diccionario NotificationOptions válido. Cuando reformateamos el mensaje push para que sea un JSON declarativo válido, es muy sencillo reescribir el Service Worker para gestionarlo.

Extraemos el elemento “notificación” del JSON, extraemos el título y lo pasamos a showNotification tal como está.

Después de refactorizar el JSON de los mensajes push y el gestor de eventos push de tu Service Worker, los mensajes son compatibles con todos los navegadores.

Los navegadores compatibles con Web Push declarativo los gestionan de forma fiable y eficaz.

Los navegadores no compatibles con Web Push declarativo los manejan con JavaScript, como todos los mensajes Web Push originales. Nos entusiasma el Web Push declarativo y esperamos que funcione para todo el mundo. Pruébalo en Safari 18.5 y posteriores en macOS, o en apps web en la pantalla de inicio en iOS 18.4 y iPadOS 18.4 y versiones posteriores.

Si es la primera vez que admites Web Push en tu app, puedes optar por el formato declarativo desde el primer día. Si ya usas Web Push, no hay mejor momento para comenzar la transición. Alejarse del formato heredado de notificación push de Safari, que es declarativo, nunca fue tan fácil. Cuando lo adoptes, ten a mano los recursos de esta sesión para enviar tus comentarios a la comunidad de estándares web o al proyecto WebKit.

También puedes consultar estas sesiones para saber cómo los navegadores admiten Web Push en general, así como las novedades de Safari y WebKit de este año.

Gracias por acompañarnos.