Most of this exists in activitree:push.
- it is easy to get it working with both web and Cordova
- it is based on Firebase which means a single SDK for all IOS and Android, Web
- " * adds a layer of latency between your service and customer" - I am not sure what this means.
- the package is not abandoned it just has no contribution from people who consume the package or other developers. It is a complex package and not many want to get into Google APIs but that is all sorted out. The problem, as usual, is that small projects want everything for free, up to date, plug and play. It is just the nature of open source. More on this at the end of my reply.
You cannot know where people are signed in because this is between your hardware and the FCM. You may know if you subscribed or unsubscribed but this data is not reliable, it is hard to keep in sync with reality. If a device is switch off, you don’t get notification. If you are subscribed and the device is on, you get them and you can unsubscribe the device. On Android you can subscribe to topics and as a platform send Push to topics instead of devices (such as news). You pause push on a device if the device is unsubscribed. You can also delete all tokens older than which is the actual recommendation and resubscribe every time you start an app.
“maybe difficult; do not send push notification if the device has an active websocket session” - this is not difficult but the standard is different. You have a behavior when the app is not in focus and another when the app is in focus. You build on these two options such as, when the app is in focus, the notification is silent and it transfers and object which you use to display an on-screen notification. Advertising uses this a lot.
I was saying in another thread, or maybe in this one somewhere near the top, the way I see it and the way it is built now (but not released before Meteor 3):
- Email and Push ar built into a Notifications system.
- Has 2 tiers:
-
- Small output, runs on the existing Meteor servers.
-
- Large - runs on dedicate Meteor server, supports queues of millions Push notifications and emails (at the speed allowed by FCM and the email providers. SES of AWS has something like 14 emails per second which can be increased, with up to 50 recipients per email. Use case: notify a user to change a password or run a large campaigns or send a promotion to all subscribers, etc.
In an infrastructure you can have any number of Meteor servers exploiting a Notifications server.
Any Notification server can be a sender of Master Push and/or Master Email or a slave.
A push Slave just deals with Client tokens, generates and saves Push Notifications to the DB but doesn’t do the actual job of sending the Push via FCM. Same for the email. Things are getting set via env vars such as:
SERVER_IS_PUSH_SAVER: true,
SERVER_IS_PUSH_SENDER: true, // fires FCM out
SERVER_IS_PUSH_SAVER: true, // enable the client (web or Cordova) to start dealing with Push workflows.
PUSH_DEBUG: false,
EMAIL_DEBUG: false,
SERVER_IS_EMAIL_SENDER: true, // fires Emails out
EMAIL_SEND_INTERVAL: 1000, // use your provider ratios
EMAIL_SEND_BATCH_SIZE: 12, // use your provider ratios
EMAIL_SEND_TIMEOUT: 10000,
I think this should not be in the core. Push is just too complex and too much of a third party thing.
), so we’re free from some shackles we previously had.