Cómo funciona el envío

Antes de entrar en la API, analicemos el envío desde un nivel alto, de principio a fin. Así, a medida que revisemos los temas o las APIs individuales más adelante, tendrás una idea de cómo y por qué es importante.

Estos son los tres pasos clave para implementar el envío:

  1. Agregar la lógica del lado del cliente para suscribir a un usuario al envío (es decir, el JavaScript y la IU en tu app web que registra a un usuario para que envíe mensajes).
  2. La llamada a la API de tu backend o aplicación que activa un mensaje push al dispositivo de un usuario.
  3. El archivo JavaScript del service worker que recibirá un “evento push” cuando el envío llegue al dispositivo. Es en este JavaScript que podrás mostrar una notificación.

Veamos con más detalle lo que implica cada uno de estos pasos.

Paso 1: Del lado del cliente

El primer paso consiste en “suscribir” un usuario a la mensajería push.

Suscribirse a un usuario requiere dos cosas. Primero, obtener el permiso del usuario para enviarle mensajes push. Segundo, obtener un PushSubscription del navegador.

Un PushSubscription contiene toda la información que necesitamos para enviar un mensaje push a ese usuario. Puedes "en cierto modo" pensar en esto como un ID para el dispositivo de ese usuario.

Todo esto se hace en JavaScript con la API de Push.

Navegadores compatibles

  • 42
  • 17
  • 44
  • 16

Origen

Antes de suscribir un usuario, deberás generar un conjunto de “claves de servidor de aplicaciones”, que abordaremos más adelante.

Las claves del servidor de aplicaciones, también conocidas como claves VAPID, son exclusivas de tu servidor. Permiten que un servicio de envío sepa qué servidor de aplicaciones suscribió a un usuario y se asegura de que sea el mismo servidor que activa los mensajes de envío para ese usuario.

Una vez que hayas suscrito al usuario y tengas un PushSubscription, deberás enviar los detalles de PushSubscription a tu backend o servidor. En tu servidor, guardarás esta suscripción en una base de datos y la utilizarás para enviar un mensaje push a ese usuario.

Asegúrate de enviar la PushSubscription a tu backend.

Paso 2: Envía un mensaje push

Cuando quieras enviar un mensaje push a tus usuarios, tienes que hacer una llamada a la API a un servicio push. Esta llamada a la API incluiría qué datos enviar, a quién enviar el mensaje y cualquier criterio sobre cómo enviarlo. Por lo general, esta llamada a la API se realiza desde tu servidor.

Estas son algunas preguntas que podrías hacerte:

  • ¿Quién y qué es el servicio push?
  • ¿Cómo se ve la API? ¿Se trata de JSON, XML o algún otro error?
  • ¿Qué puede hacer la API?

¿Quién y qué es el servicio push?

Un servicio push recibe una solicitud de red, la valida y entrega un mensaje push al navegador adecuado. Si el navegador está sin conexión, el mensaje permanecerá en cola hasta que se conecte.

Cada navegador puede usar el servicio push que quieran; es algo que los desarrolladores no controlan. Esto no es un problema, ya que todos los servicios de envío esperan la misma llamada a la API. Esto significa que no tienes que preocuparte por quién es el servicio de envío, sino que solo debes asegurarte de que tu llamada a la API sea válida.

Para obtener la URL adecuada para activar un mensaje de envío (es decir, la URL del servicio de envío), solo debes ver el valor endpoint en un PushSubscription.

A continuación, se muestra un ejemplo de los valores que obtendrás de una PushSubscription:

{
  "endpoint": "https://random-push-service.com/some-kind-of-unique-id-1234/v2/",
  "keys": {
    "p256dh": "BNcRdreALRFXTkOOUHK1EtK2wtaz5Ry4YfYCA_0QTpQtUbVlUls0VJXg7A8u-Ts1XbjhazAkj7I99e8QcYP7DkM=",
    "auth": "tBHItJI5svbpez7KI4CCXg=="
  }
}

El extremo en este caso es [https://random-push-service.com/some-kind-of-unique-id-1234/v2/]. El servicio de envío sería “random-push-service.com” y cada extremo es único para un usuario, indicado con “some-kind-of-unique-id-1234”. Cuando empieces a trabajar con Push, notarás este patrón.

Las claves de la suscripción se analizarán más adelante.

¿Cómo se ve la API?

Mencioné que todos los servicios push web esperan la misma llamada a la API. Esa API es el protocolo de envío web. Es un estándar IETF que define cómo realizar una llamada a la API para un servicio push.

La llamada a la API requiere que se configuren ciertos encabezados y que los datos sean un flujo de bytes. Veremos bibliotecas que pueden realizar esta llamada a la API por nosotros y cómo hacerlo nosotros mismos.

¿Qué puede hacer la API?

La API proporciona una manera de enviar un mensaje a un usuario, con o sin datos, y proporciona instrucciones sobre cómo enviar el mensaje.

Los datos que envíes con un mensaje push se deben encriptar. El motivo es que evita que los servicios de envío, que pueden ser cualquiera, puedan ver los datos enviados con el mensaje push. Esto es importante, ya que es el navegador el que decide qué servicio push usar, lo que podría abrir la puerta a los navegadores que usen un servicio push que no es seguro.

Cuando actives un mensaje de envío, el servicio de envío recibirá la llamada a la API y el mensaje se pondrá en cola. Este mensaje permanecerá en cola hasta que el dispositivo del usuario esté en línea y el servicio de envío pueda entregarlos. Las instrucciones que puedes dar al servicio de envío definen cómo este mensaje se pondrá en cola.

Las instrucciones incluyen detalles como los siguientes:

  • El tiempo de actividad para un mensaje push. Esto define cuánto tiempo se debe poner en cola un mensaje antes de que se quite y no se entregue.

  • Define la urgencia del mensaje. Esto es útil en caso de que el servicio de envío conserve la duración de batería de los usuarios solo con la entrega de mensajes de alta prioridad.

  • Asígnale un nombre a “tema” a un mensaje push. Este reemplazará todos los mensajes pendientes con este nuevo mensaje.

Cuando tu servidor desea enviar un mensaje de aplicación, realiza una solicitud de protocolo push web a un servicio de envío.

Paso 3: Envía el evento al dispositivo del usuario

Una vez que hayamos enviado un mensaje push, el servicio de este mantendrá tu mensaje en su servidor hasta que ocurra uno de los siguientes eventos:

  1. El dispositivo se conecta y el servicio de envío entrega el mensaje.
  2. El mensaje vence. Si esto ocurre, el servicio de envío quita el mensaje de su cola y nunca se entregará.

Cuando el servicio push entregue un mensaje, el navegador lo recibirá, desencriptará los datos y enviará un evento push en tu service worker.

Un service worker es un archivo JavaScript "especial". El navegador puede ejecutar este JavaScript sin que se abra la página. Incluso puede ejecutar este JavaScript cuando el navegador está cerrado. Un service worker también tiene APIs, como push, que no están disponibles en la página web (es decir, APIs que no están disponibles fuera de una secuencia de comandos de service worker).

Dentro del evento "push" del service worker puedes realizar cualquier tarea en segundo plano. Puedes hacer llamadas de estadísticas, almacenar páginas en caché sin conexión y mostrar notificaciones.

Cuando se envía un mensaje push desde un servicio push al dispositivo de un usuario, tu service worker recibe un evento push.

Ese es todo el flujo para los mensajes de aplicación.

Próximos pasos

Code labs