necesito usar firebase obligado?
No.
Hay muchos proveedores, con distintos precios y features. Me ha tocado usar solamente Firebase y OneSignal, y diría que para elegir proveedor los factores relevantes incluyen la calidad de la documentación, la cantidad de preguntas en Stack Overflow, la existencia de librerías para el lenguaje de programación de tu app, las integraciones con otros servicios, o los servicios complementarios.
Me da la impresión que OneSignal es más fácil de implementar y su servicio es mayormente enfocado en las notificaciones. Por el contrario, Firebase es más complejo de configurar y la documentación no es muy didáctica. Sin embargo vale la pena tener en cuenta que Firebase le lleva muchos otros servicios (A/B testing, remote config, contextual links, analytics, hosting, realtime database, single sign on, APM, publicidad... ) así que dependiendo de cuánto de eso quieras usar, la dificultad inicial puede valer la pena con creces.
Voy a usar firebase para responder lo que sigue.
Necesito guardar todos esos datos?
Cuando un usuario acepta recibir ~spam~ er digo, notificaciones, se genera un
notification_token, también llamado
device_id y
registracion_id dependiendo del proveedor, pero es lo mismo. (en tu endpoint, lo que empieza con
cAb65LUDH_A:APA91bGp_aaaaaaaaaaaULia8wHb_bsqiwTgtBPGpT4Pv...) Eso lo debes enviar al backend para persistirlo en la BBDD. Mira el comentario en el ejemplo de firebase:
Send the token to your server and update the UI if necessary
Código:
const messaging = getMessaging();
getToken(messaging, { vapidKey: '<YOUR_PUBLIC_VAPID_KEY_HERE>' }).then((currentToken) => {
if (currentToken) {
// Send the token to your server and update the UI if necessary
// ...
} else {
// Show permission request UI
console.log('No registration token available. Request permission to generate one.');
// ...
}
}).catch((err) => {
console.log('An error occurred while retrieving token. ', err);
// ...
});
En adelante, cuando quieras enviarle una notificación usarás ese token como destinatario.
Como el mismo usuario se puede meter a tu app con varios browsers, con el teléfono, el ipad y la pantalla mágica, puede tener muchos tokens. Así que se guardan en un modelo independiente, sobre el cual el usuario tiene relación 1:N. El SDK permite enviar notificaciones poniendo un array de tokens como destinatario, pero también permite crear grupos de tokens y mandar el mensaje al grupo, para ahorrar dolores de cabeza. Y de paso también puedes suscribir tokens a un tópico y mensajear a todos los suscriptores de éste. Como uno elige el slug del tópico o del grupo, es fácil usar algo que sea único por usuario (el slug de su mail por ejemplo).
como envio una notificacion usando postman? todo lo que veo en internet son tutoriales que usan firebase.
No tiene mucha ciencia hacerlo con Postman o con curl o desde cualquier app server-side que pueda hacer requests.
El formato legacy es
Código:
POST https://fcm.googleapis.com/fcm/send
Content-Type:application/json
Authorization:key=AIzaSyZ-1u...0GBYzPu7Udno5aA
{
"notification":{
"title":"MyDot vuelve recargado",
"body":"Hola! Haz click ahora! ¡Estamos entregando tus productos en menos de 60 minutos!"
},
"to" : "cAb65LUDH_A:APA91bGp_aaaaaaaaaaaULia8wHb_bsqiwTgtBPGpT4Pv..."
}
el atributo
to es el registration_id del destinatario, mientras que el header authorization es
key=<FCM_SERVER_KEY>, llave complementaria a la que usaste para pedir autorización al inicio. No hay nada encriptado ahí.
Por otro lado: el formato legacy se llama así porque hay otro formato moderno que es el recomendado en la actualidad.
Por ejemplo
Código:
POST https://fcm.googleapis.com/v1/projects/<NOMBRE_DE_PROYECTO>/messages:send HTTP/1.1
Content-Type: application/json
Authorization: Bearer ya29.ElqKBGN2Ri_Uz...PbJ_uNasm // tu
{
"message": {
"token" : "cAb65LUDH_A:APA91bGp_aaaaaaaaaaaULia8wHb_bsqiwTgtBPGpT4Pv..."
"notification": {
"title": "FCM Message",
"body": "This is a message from FCM"
}
}
}
Este payload (el json) tiene una propiedad
message, y dentro de ésta va un objeto parecido al legacy, salvo porque en vez de una propiedad
to usas una propiedad
token. Esto tiene una buena razón de ser, que explicaré más abajo.
También tenemos la posibilidad de usar el SDK. Firebase tiene SDK para cualquier lenguaje, y está pensado para correr en el servidor. Cuando instancias el cliente de Firebase con tus credenciales él se preocupa de autorizar tus envíos, así que sólo le pasas el payload a un método. No me acuerdo si era igual que el del formato moderno o le pasas sólo el contenido de
message.
Finalmente, el dashboard de firebase console tiene una interfaz web para enviar notificaciones de prueba.
Sobre el uso de
token en reemplazo de
to, se debe a la unificación de lo que antes eran distintos endpoints para enviar notificaciones a un token, un grupo o un topic. Ahora eso se distingue
según le hayas puesto una propiedad topic, token o to. Esta última se usa sólo para grupos. Debieran haberle puesto
group, digo yo.
El payload de la notificación tiene muchas otras propiedades que se usan para customizar su comportamiento. Según se reciba en un browser, android o iphone:
Código:
{
"to": "<group_unique_id>",
"data": {
"notification_type": "aviso"
},
"notification": {
"title": "Capa9 vuelve recargado",
"body": "Métete al foro pos, tetón"
},
"android": {
"collapse_key": "Nuevos reviews en Capa9",
"ttl": 7600000,
"priority": "HIGH",
"notification": {
"event_time": "2019-10-25T16:19:21.791Z",
"visibility": "PUBLIC",
"notification_priority": "PRIORITY_HIGH",
"icon": "fcm_push_icon",
"tag": "Capa9",
"color": "#55A07A",
"sound": "default"
},
"fcm_options": {
"analytics_label": "usuarios_que_han_posteado"
}
},
"webpush": {
"headers": {
"TTL": "120",
"Urgency": "high",
"Topic": "Capa9"
},
"notification": {
"badge": "fcm_push_icon.png",
"icon": "img/icons/android-icon-72x72.png",
"tag": "Capa9",
"timestamp": 1572020361791,
"vibrate": [
200,
100,
200
]
},
"fcm_options": {
"analytics_label": "usuarios_que_han_posteado"
}
},
"apns": {
"headers": {
"apns-priority": "10",
"apns-collapse-id": "Nuevos reviews en Capa9"
},
"fcm_options": {
"analytics_label": "usuarios_que_han_posteado"
}
},
"fcm_options": {
"analytics_label": "usuarios_que_han_posteado"
}
}
A diferencia del caso webpush, para obtener autorización en apps nativas las llaves son un poco más seguras que un simple string, y se suben como certificado a la consola de firebase.
Acerca de enviar una notificación usando Postman, sospecho que va a ser bastante complicado debido a que el contenido a enviar debe ser encriptado en base a la especificación de Web Push.
Cuando usas un proveedor, éste se ocupará de hacer la encriptación a partir del payload que le envíes y las llaves que tengas cargadas en el proyecto. El rol del proveedor como broker de las notificaciones facilita harto la implementación y todos tienen features adicionales para que valga la pena el servicio. Onda segmentar destinatarios, o llevar analíticas, invitar colaboradores al proyecto, plugins para frameworks populares.
De todas maneras es loable que hayas aprendido a implementar el flujo por tu cuenta. El día de mañana cuando salgan APIs emparentadas a Web Push vas a cachar a la primera, mientras que yo seguro estaré puteando a Firebase por sus métodos inconsistentes entre cada servicio.
web.dev
He seguido parte de la guia y llegue a un punto donde logre suscribir a un cliente, y me manda la siguiente informacion.
