Cómo añadir notificaciones a tu app: en la app, por correo y push

Para añadir notificaciones a una app web, empieza por las notificaciones dentro de la app: una tabla de notificaciones en tu base de datos y un icono de campana que muestre los elementos no leídos. Añade el correo para las cosas que la gente necesita saber cuando no está en la app, usando un proveedor de correo, y añade push web solo cuando los avisos puntuales importen, ya que requiere un service worker, el permiso del usuario y, en el iPhone, que la app esté guardada en la pantalla de inicio. Con los canales que uses, crea cada notificación en un único lugar en el servidor y deja que los usuarios elijan qué quieren recibir.

Esta guía compara los canales, muestra una arquitectura sencilla y da prompts que puedes usar con un constructor de apps con IA.

Los canales principales, comparados

La mayoría de las apps necesitan dentro de la app más correo. El push y el SMS merecen la pena cuando el momento importa de verdad, como un recordatorio de reserva o un pedido que ya está listo.

Cómo encaja un sistema de notificaciones

Mantenlo simple y centralizado:

1. Pasa algo. Se publica un comentario, falla un pago, una reserva es mañana.
2. Tu servidor llama a una sola función, como notify(user, type, data).
3. Esa función revisa las preferencias del usuario y escribe una fila en la tabla notifications (para la campana).
4. Después envía a los demás canales que el usuario haya activado para ese tipo: correo a través de tu proveedor, push a través de la API Push.
5. El frontend muestra las notificaciones no leídas y las marca como leídas al abrirlas.

Un único punto de entrada permite añadir un canal, cambiar el texto o respetar las preferencias sin buscar por todo el código.

Qué guardar

Una tabla de notificaciones suele necesitar: ID de usuario, tipo (por ejemplo comment_reply), un título y un cuerpo cortos, un enlace a la página correspondiente, la fecha de creación y la de lectura. Una tabla de preferencias aparte guarda qué canales quiere cada usuario para cada tipo.

Mostrar las notificaciones nuevas

• Cargar al ver la página y consultar cada 30–60 segundos. Sencillo y fiable.
• Actualizaciones en tiempo real con WebSockets o server-sent events: se sienten instantáneas, pero añaden piezas móviles. Empieza con las consultas periódicas, salvo que las actualizaciones instantáneas sean imprescindibles.

Notificaciones por correo

El correo necesita un proveedor de envío y un dominio verificado; los detalles están en cómo enviar correos desde tu app. Para las notificaciones en concreto:

• Envía desde el servidor, nunca con una clave del proveedor en el navegador.
• Agrupa los eventos frecuentes. «3 comentarios nuevos» en un solo correo es mejor que tres correos.
• Ofrece un resumen diario o semanal para la actividad de baja prioridad.
• Incluye un enlace para darse de baja o para las preferencias en los correos no esenciales. Las normas sobre el correo de marketing varían según el país; comprueba lo que te aplica.

Notificaciones push web

El push web permite que tu sitio envíe avisos que aparecen como notificaciones de una app. Según la documentación de la API Push de MDN, funciona así:

1. Tu sitio registra un service worker, un script que el navegador puede ejecutar en segundo plano.
2. Cuando el usuario acepta, el service worker se suscribe mediante PushManager.subscribe(). El navegador devuelve una suscripción con un endpoint y claves de cifrado.
3. Tu servidor guarda esa suscripción y, cuando pasa algo, envía un mensaje al endpoint, normalmente firmado con claves VAPID (un par de claves que identifica a tu servidor).
4. El navegador arranca tu service worker, que muestra la notificación, aunque tu página no esté abierta.

MDN también señala que el endpoint debe mantenerse en secreto, porque conocerlo basta para enviar mensajes a ese usuario.

iPhone y iPad

WebKit añadió Web Push para apps web en iOS y iPadOS 16.4, con dos condiciones de su anuncio: el sitio debe añadirse a la pantalla de inicio, y el permiso debe pedirse como respuesta a una acción del usuario, como tocar un botón de Suscribirse. Así que en el iPhone el push solo llega a los usuarios que han instalado tu app web. Consulta apps nativas frente a apps web progresivas para saber qué significa instalar una app web.

Pedir permiso bien

No lo pidas en la primera visita. Explica primero el beneficio («Recibe un recordatorio una hora antes de tu clase») y muestra el aviso del navegador cuando el usuario toque un botón. Si alguien lo rechaza, el navegador puede no dejarte volver a preguntar, así que un aviso prematuro puede perder a esa persona para siempre.

Las notificaciones programadas necesitan un disparador

«Recordatorio 24 horas antes» o «resumen semanal cada lunes» necesitan algo que se ejecute según un horario. Eso es un problema de tareas en segundo plano, que se trata en cómo ejecutar tareas en segundo plano. Un patrón habitual: un programador externo llama a un endpoint protegido cada pocos minutos, y ese endpoint envía lo que toque.

Prompts para tu constructor de IA

Empieza por lo de dentro de la app:

Añade notificaciones dentro de la app. Crea una tabla de notificaciones (usuario, tipo, título, cuerpo, enlace, created_at, read_at). Añade una función de servidor notify(userId, type, data) que llame cada funcionalidad. Muestra un icono de campana en la cabecera con un contador de no leídas, un desplegable con las 20 últimas y un botón de «marcar todas como leídas». Consulta si hay nuevas cada 60 segundos.

Después, preferencias y correo:

Añade ajustes de notificaciones: para cada tipo (respuestas a comentarios, menciones, facturación), el usuario elige dentro de la app, correo, ambos o ninguno. notify() debe respetarlos. Envía el correo a través de [PROVIDER] usando el secreto [ENV_NAME] solo en el servidor. Agrupa los correos de comentarios para que cada usuario reciba como máximo uno cada 15 minutos.

Después, push, si lo necesitas:

Añade push web opcional. Registra un service worker, genera claves VAPID y guarda la clave privada como secreto. Añade un botón «Activar notificaciones» en los ajustes que pida el permiso solo al hacer clic. Guarda cada suscripción por usuario y dispositivo, envía los push desde notify() cuando el usuario haya dado su consentimiento y elimina las suscripciones que el servicio push indique como caducadas.

Errores habituales

• Notificaciones repartidas por el código. Cada funcionalidad envía su correo a su manera y las preferencias se ignoran. Usa una sola función notify().
• Pedir el permiso de push al cargar la página. La mayoría lo rechaza, y puede que no tengas otra oportunidad.
• Sin preferencias. Los usuarios que no pueden desactivar avisos molestos los desactivan todos, o se van.
• Enviar desde el navegador. Las claves de correo y de push deben estar en el servidor.
• No limpiar las suscripciones push caducadas. Se acumulan y desperdician envíos.
• Datos sensibles en el texto de la notificación. Las pantallas de bloqueo lo muestran. «Tienes un mensaje nuevo» es más seguro que el propio mensaje.
• Ningún registro de lo enviado. Cuando un usuario dice «nunca me llegó el correo», los registros con los ID de mensaje del proveedor te ayudan a averiguar por qué.

Lista de comprobación

• Una única función notify() en el servidor, usada en todas partes
• Tabla de notificaciones con estado de lectura, y una campana con contador de no leídas
• Preferencias de canal por tipo, respetadas por notify()
• Correo enviado desde el servidor con un dominio verificado; resumen o agrupación para los eventos frecuentes
• Permiso de push pedido solo tras una acción del usuario, con una explicación
• Push probado en el escritorio y en un iPhone con la app añadida a la pantalla de inicio
• Suscripciones push caducadas eliminadas
• Sin contenido sensible en las vistas previas de push o de correo
• Los recordatorios programados tienen un disparador fiable

Notificaciones en Mythex

Mythex no incluye un servicio de correo ni de push integrado para las apps que construyes, así que traes tu propio proveedor de correo y generas tus propias claves push, guardadas como secretos del proyecto. La parte dentro de la app solo necesita la base de datos del proyecto, que Mythex añade cuando la pides. Construye con prompts como los de arriba, prueba la campana y los correos en la vista previa, y prueba el push en tu URL publicada, ya que los service workers y el push necesitan una dirección HTTPS real. La receta de la documentación Enviar correo desde tu app incluye un prompt de inicio. Mythex no documenta trabajos programados, así que planifica los recordatorios con un disparador externo como se describe en cómo ejecutar tareas en segundo plano.

Preguntas