Las notificaciones push son un excelente método para poder comunicarnos con nuestros usuarios porque, de manera inmediata, permiten tenerles al tanto de todas las actualizaciones de nuestro sitio, incluso cuando el navegador se encuentra cerrado. Por ese motivo, las notificaciones se están extendiendo cada vez más entre aplicaciones y páginas web y es una de la tendencias más marcadas. En este artículo veremos, desde un punto de vista bastante teórico, los diferentes elementos que tienen que sincronizarse a la perfección y que están involucrados en el envío y recepción de una notificación push.
Principales integrantes del servicio
Resumiendo mucho, estos son los tres principales integrantes que intervienen en el envío de las notificaciones, y debajo hablamos de otros elementos determinantes en el proceso:
- El navegador o cliente web. Tendremos que tener permiso del navegador para que podamos enviar las notificaciones. Las últimas versiones de los navegadores más extendidos ya dan soporte a las notificaciones push y el resto lo integrarán pronto.
- El servidor de notificaciones al que hay que invocar para que realice la notificación al navegador. Entre ellos, Google Cloud Messaging (GCM) o, si optamos por Firebase, Firebase Cloud Messaging (FCM), aunque básicamente son lo mismo.
- Nuestro backend. Tendremos que crear nuestras notificaciones del lado del servidor. Ahí definiremos qué usuarios las recibirán y cuándo serán enviadas por el servidor de noficaciones.
Si no tenemos backend para el envío, se puede realizar con cualquier lenguaje de programació, ya que las comunicaciones con el servidor de mensajería se pueden hacer por el protocolo HTTP. Además, con Curl, podemos empezar a experimentar con las notificaciones sin ningún tipo de código del lado del servidor, apoyándonos en la línea de comandos.
Archivo manifest.json
Además, las notificaciones necesitan tener configurado el archivo manifest.json en el directorio raíz del dominio. A continuación, lo crearemos con el contenido mínimo necesario.
{
"gcm_sender_id": "103953800507"
}
Puedes ver que le estamos indicando el Google Cloud Messaging Sender ID con un valor fijo. Indispensable respetar ese valor si nos estamos apoyando en el servicio de Firebase para el envío de notificaciones. Recientemente, hablamos largo y tendido sobre el archivo manifiesto en las Progressive Web Apps.
Service worker
También tenemos que prestar atención el service worker, que es necesario para dar soporte a muchas de las utilidades de las mencionadas Progressive Web Apps. Consiste en un script que queda residente en el navegador, en el que asociamos el sitio web y que se ejecuta sin que necesariamente lo tengamos abierto. El service worker es imprescindible para que podamos recoger las notificaciones que recibimos cuando nuestro sitio web no está visible y que éstas se muestren al usuario. Estas notificaciones podemos recibirlas en dos escenarios diferentes:
- En caso de que el sitio web esté visible, la notificación se recibe como un evento dentro del propio sitio. Para ello, el navegador deberá estar arrancado con el sitio abierto en una pestaña visible.
- Si por el contrario el sitio no está visible, la notificación pasa a recibirse como una notificación del sistema operativo. En este caso, puede que el sitio web no esté abierto o que no se esté mostrando en la pestaña visible en ese momento.
Para las situaciones en las que el usuario no tiene el navegador abierto, éste no recibirá las notificaciones hasta que no vuelva a abrirlo, mostrándose entonces desde el sistema operativo y encoladas, teniendo en cuenta que existe un límite de encolado.
Aunque lo habitual para Firebase es que el archivo service worker sea firebase-messaging-sw.js, existe la posibilidad de darle un nombre distinto con la API de notificaciones de Firebase. Una vez elegido el nombre del archivo, debe colocarse en la raíz del dominio, como podemos ver aquí.
El código que contiene el archivo se puede quedar intacto en el service worker, debiendo solamente editar el sender id en la línea messagingSenderId’: ‘YOUR-SENDER-ID. El sender id es una cadena numérica que se encuentra entre las configuraciones de inicialización de una app Firebase y se puede obtener desde la consola de Firebase o desde el enlace Configuración de proyecto, que se encuentra junto a la rueda dentada.
Si lo hacemos desde allí, nos dirigiremos a la pestaña con la opción Mensajería en la nube para encontrar el Id del remitente y la Clave de servidor, que es secreta y que necesitaremos para el código backend.
Sobre el código de service worker debe aparecer el código que nos interesa de momento. Por tanto, no es necesario utilizarlo al completo, bastando con que copiemos el código hasta la línea const messaging = firebase.messaging(); que sería la última línea de nuestro archivo firebase-messaging-sw.js.
Token
El uso de un token es habitual en el envío de las notificaciones y que tenemos que conseguir durante el proceso de implementación. Lo que hace el token es relacionar un navegador o dispositivo con un sitio web. Realmente es la dirección de envío para el servicio de mensajería. El envío de una notificación se realiza con el token del usuario. Desde el backend, que hayamos creado, se envían las notificaciones, por lo que tendremos que agenciarnos un modo para enviar ese token al backend y así enviar la notificación desde allí. Como estás utilizando Firebase, puedes guardar el token en la base de datos, a la que puedes acceder desde cualquier lenguaje del lado del servidor.
En este mismo blog, encontrarás también distintos tutoriales y artículos prácticos sobre notificaciones push, como ¿Qué son las notificaciones push y cómo incluirlas fácilmente en una página hecha con WordPress?, Aprende a implementar notificaciones Push con Firebase y Cómo enviar notificaciones desde el backend.