Notificaciones Push: No se puede vivir con ellas, no se puede vivir sin ellas

Cuando era niño en Estados Unidos, de padres israelíes, la mayoría de mis libros y películas desde muy temprana edad eran en hebreo, por supuesto, para enseñarme el idioma antes de que el inglés se apoderara de mi cerebro.

Una cinta que me encantaba se llamaba Hakina Nekhama, Nekhama el Piojo, que si no estás familiarizado con esta palabra, es la versión singular de piojos. Asqueroso, lo sé.

La historia contaba de este piojo que decidió que no quería quedarse en una cabeza para siempre. Quería salir y viajar por el mundo, ver diferentes cabezas y diferentes ciudades. Pero obviamente todos la odiaban y querían que se fuera, y ella viajaba incansablemente de una cabeza a otra hasta que accidentalmente aterriza en la cabeza de un hombre calvo, quien en realidad está muy emocionado de tenerla porque ahora tiene el mismo problema que las personas con cabello. Se hacen amigos y viven felices para siempre.

Ahora, obviamente esta es una historia ridícula, pero cuando me uní a Vonage el año pasado y aprendí sobre nuestra plataforma de comunicaciones y la cantidad de mensajes que maneja al día, consideré la notificación única entre un millón que se abre camino en un viaje rápido de 5, 10, solo milisegundos llegando a donde necesita estar, de repente me hizo pensar en ese pequeño piojo rosa que amaba de niño, uno entre un millón, que con propósito y ambición finalmente llegó a la cabeza del hombre calvo que la quería, su pareja perfecta, precisamente donde necesitaba estar. ¿Milagroso, no?

Pero aquí está la cosa, en el mundo de los libros infantiles, todo termina felizmente, pero en la vida real, las cosas no salen como se planean, los objetos se pierden, las notificaciones nunca llegan a su destino, así que hablemos de esta vida real de la ingeniería de infraestructura, de rastrear nuestros pasos y asegurarnos de saber qué está sucediendo en cada punto del peligroso viaje.

La plataforma de Comunicaciones Empresariales de Vonage, el sistema del que hablaré hoy, ofrece capacidades de voz, mensajería, video y correo de voz tanto en escritorio como en dispositivos móviles. La plataforma cuenta con 150,000 usuarios que a través de todas estas funcionalidades producen 800 notificaciones por segundo. ¿Y lo mejor? Todas esas notificaciones llegan a donde necesitan estar en 15 milisegundos, porque ese es el tipo de estándares a los que estamos acostumbrados hoy en día. Entonces, ¿cómo es este viaje de 15 milisegundos de una linda notificación? Comencemos desde el principio.

Digamos que estás en tu computadora usando la aplicación de escritorio. Tu computadora, a través del cliente, se conecta a la infraestructura de mensajería que llamamos la estación de autobuses y se presenta, `Hola, pertenezco a la computadora de Juan. Me gustaría registrarme para recibir notificaciones`. La estación de autobuses envía una solicitud a su API, que hemos llamado Frizzle porque las referencias a los libros infantiles nunca terminan, para informarle sobre la nueva conexión. Toda la información de identificación se almacena. Frizzle se comunica con el intermediario de mensajes, que crea una nueva cola para tu usuario en particular y, con la ayuda del protocolo de mensajes, determina en qué cola colocar tus mensajes. El protocolo devuelve una URL y así se forma una conexión WebSocket entre tu cliente y esta cosa que llamamos el autobús. Ahora, en el otro extremo, se envía un mensaje hacia ti. Llega a la API de Frizzle perteneciente al autobús, y Frizzle envía la notificación a RabbitMQ, y el Protocolo de Mensajes la envía a tu dispositivo. Genial.

Pero te preguntas ahora, ¿qué pasa con los teléfonos móviles? ¿La aplicación móvil? No puedo mantener una conexión WebSocket con el teléfono todo el tiempo, ¿verdad? Entonces, ¿qué pasa con esas famosas notificaciones push del título de mi charla? Y lo que es más importante, ¿cómo sigo el progreso de esas notificaciones? Porque con 800 notificaciones por segundo, puede ser muy fácil perder rápidamente el rastro. Bueno, cuando abres la aplicación móvil, ocurre un flujo similar. Tu teléfono se conecta a la estación de autobuses y se presenta con tu ID e información sobre tu dispositivo y algo llamado un token de notificación, asumiendo que hiciste clic en Permitir Notificaciones en la aplicación. La API maneja y almacena esta información, y ahora estás registrado para recibir notificaciones. Ahora, cuando Frizzle envía la notificación a tu cola, esa notificación también se envía en paralelo a lo que llamamos el servicio HTTP del autobús. Escrito en Node, el servicio sabe si te has registrado para recibir notificaciones push.

Si tienes, la notificación y tu información se envía a PushMe, otro servicio de Node para notificaciones push. Este servicio tiene una base de datos de esos tokens de push mapeados a cada usuario, que le indican a qué sistema operativo y a qué dispositivo enviar esa notificación push. Ahora, con una infraestructura en su lugar, ¿cómo podemos garantizar la llegada de 16 millones de notificaciones diarias? La respuesta obvia son los IDs de rastreo en los registros, asegurando que el mismo ID siempre se use para la notificación específica en cada servicio, ¿verdad? Pero, ¿cómo lo hacemos mientras separamos la lógica empresarial de la infraestructura? No queremos que un ID de rastreo aparezca por todo nuestro código, ¿verdad? Aquí es donde entra en juego un práctico paquete de NPM.

Y esta parte es importante incluso si no estás tratando de construir una plataforma de comunicaciones masiva. Estoy hablando de un paquete de almacenamiento local de continuación o gancho CLS que utiliza ganchos asíncronos para mantener algo como un almacenamiento local para cada sesión de solicitud. Si ya estás utilizando Node 14, sin embargo, esta funcionalidad está incorporada con una API nativa experimental. Permite que el ID de rastreo se guarde en el almacenamiento local para que se pueda recuperar para cualquier registro y cualquier solicitud en cualquier punto del flujo.

Entonces, consideremos esta parte del diagrama. Imagina una notificación push dirigida a tu teléfono que te dice que recibiste un mensaje de Jonathan. Como sabemos, Frizzle envía esta notificación como una solicitud al servicio HTTP del autobús. Al llegar al servicio HTTP, el middleware obtiene el ID de rastreo de las cabeceras y lo coloca en el almacenamiento local de la sesión. Se escriben varios registros a medida que ocurren diferentes cosas, como verificar un rifle, por ejemplo, y encontrar información sobre el dispositivo del usuario. Y luego, cada vez, ese ID de rastreo se agrega a esos registros antes de que se escriban. Suponiendo que aceptes notificaciones push, el intérprete captura la notificación justo antes de que se dirija a PushMe y rastrea el ID de rastreo en las cabeceras de la solicitud. Lo genial es que CLSHooked se puede usar para otras cosas, no solo registros, como en una situación en la que necesitas los detalles del usuario en cada paso a lo largo del flujo de tu servicio. Pero veamos cómo se ve en nuestro código, que se ha tomado del servicio HTTP. Primero creamos una instancia del middleware de esta manera, y luego la recuperamos de esta manera. Entonces, cuando una solicitud llega al servicio y es interceptada por el middleware de rastreo, que verifica si tiene un ID de rastreo, asumiendo que llegó de Frizzle, debería, luego guarda ese ID en la instancia de almacenamiento local. Y en este punto estamos manejando la lógica empresarial, ¿verdad? Estamos verificando si debemos enviarle a este tipo una notificación push. En cada punto del camino donde se debe escribir un registro y antes de que se envíe, será capturado por el middleware aquí, que agregará el ID de rastreo tomando del almacenamiento local y luego escribirá el registro. Ahora el mismo intérprete se encuentra en Axios, el cliente HTTP, para que cada vez que una solicitud esté a punto de ir a otro servicio, capturemos esa solicitud HTTP justo antes y agreguemos el ID de rastreo a su cabecera. Y todo esto asegura que el registrador no necesite saber nada sobre el ID de rastreo. Genial, ¿verdad? Cuando PushMe finalmente envía esa notificación a tu dispositivo, tendremos ese registro final con el ID de rastreo en cuestión y sabremos que enviamos esa notificación a la tienda de aplicaciones. De esta manera, si se envió una notificación a tu teléfono y no la recibiste, podemos culpar a Apple, ¿porque no nos encanta culpar a Apple? Y esto es cómo se ven una serie de registros para una notificación de una llamada entrante. Si observas las marcas de tiempo, notarás que va desde Frizzle hasta el servicio HTTP hasta PushMe en cuestión de 4 milisegundos. Entonces, este puede no ser el viaje heroico de un lindo parásito alrededor del mundo, pero, hey, quién sabe, estos podrían ser los registros de una pequeña notificación que llegó alrededor del mundo en menos de 15 milisegundos. Gracias.