Slightly unrelated, but can anybody explain why private RSS feeds are not a more popular choice for "client push" when push lag of a couple of hours isn't a big deal? The "pill reminder" app made me think about how easy it would be to host a private RSS feed for each client that the backend updates on a schedule, and clients just... check the RSS feed for an update.
Maybe I'm missing something here, but it feels like you don't need some fancy realtime queue service for most push notifications, so why not use something that offloads the checks to the client?
RSS is a neat standard, but if you're writing your own app, you might as well use a custom JSON payload that's exactly what you need. If you use RSS but never actually use an RSS reader or expose it to the public, you may end up deviating from the standard, or doing extra work to be compliant with the standard that never gets used.
As far as push notifications, the reality is that "push" is a bit of a marketing term. Every time your phone wakes up and gets on the network, it contacts Apple or Google and sees if there are any pending pushes to be delivered. By using the "push notification" systems, you get to piggyback on that highly optimized connection already provided by Apple or Google. These pushes have to be much smaller than your typical RSS feed and are intended for high priority delivery.
An alternative, if you don't want your data going through the "push" networks, is to have your app "background fetch". You might want to do this if it's too much data (like an RSS feed would be) or if it's sensitive data (Apple and Google can obviously read all push messages). In this case, the iOS and Android have special "background fetch" use cases, which gives your app a chance to pre-load data. News apps are the canonical example.
> it feels like you don't need some fancy realtime queue service for most push notifications, so why not use something that offloads the checks to the client
Mostly because the realtime queue already exists, it's provided mostly for free, it comes with extra features like sounds and badges, it was available before background fetches, and business people know to ask for "push" by name.
I think it’s because most of the time a lag of a couple hours is in fact a big deal. Let’s look at some common use cases:
- If I want push notifications for meetings, I want to get them exactly 10 minutes before my meeting, not 2 hours after, or 10 minutes before but +/- 30 minutes
- If a customer is submitting a critical bug to my bug tracker, I want to know immediately so I can start damage control.
- If a developer on my team responds to my comments on a Pull Request at 3PM, I don’t want to get the notification after I’ve clocked out at 5, causing us to essentially lose a day of work.
In practice, I don’t think there are many use cases where people don’t care about the punctuality of push notifications. And if you start by tackling those use cases and then an important customer says “hey, I actually need punctuality for this new class of notifications”, then you’ll suddenly need to rebuild your whole notifications stack.
Yeah, I didn’t look at them at all today. I’m still alive. As a user, I don’t care about how punctual they are since I don’t look at them until the end of my work day.
At least for today, for you. Phone systems go down all the time and when that happens, people DO die. No one dies because a notification gets delayed a few hours.
Not that there is anything wrong with that, and in many use cases it would be a fine alternative. But sometimes you really do need to push data to the user even if they aren’t polling for it.
Pill reminders would be something that you’d want to push. You can’t be sure the user is running your app (even in the background), and the actual state changes are rare. So some kind of mechanism where the client doesn’t initiate the check would be better.
Using a long poll for email or slack or something like that can make more sense in some
scenarios.
I think they are differentiating between systems that perform polling and systems that can receive interrupts (maybe not quite the right word here), I don't think that has anything to do with being publicly addressable here, in either case you sort of have to assume that devices can find each other before the difference even makes sense.
Good point! In the mobile space, a certain walled-garden platform traditionally killed off any app 10 minutes after you left it, and even to this date does not guarantee that your app will be allowed to call home on any semi-regular basis. This makes it impossible to guarantee delivery without using the officially sanctioned push system. And if we're doing push already, why bother doing it differently on other platforms? (even if they support cross-app coordination to make the polling battery-efficient)
> Maybe I'm missing something here, but it feels like you don't need some fancy realtime queue service for most push notifications, so why not use something that offloads the checks to the client?
Depending on the use case, you may well depend on the real-time aspect of push notifications.
If my door bell rang while using headphones, I'd want to know immediately.
I'd also be pretty pissed if a messenger took more than 5 seconds between sending and receiving on the other end, event if "closed" or in background.
Totally fair. I mostly meant this as a replacement for notification systems that aren't super time dependent. Even 5 minute pings would probably be enough for most use cases.
Maybe I'm missing something here, but it feels like you don't need some fancy realtime queue service for most push notifications, so why not use something that offloads the checks to the client?