Update: Google Bug Report Description
(as suggested by google dev advocate in comments on answer 1, filed a bug report; updating the content here since it more succinctly and precisely describes the problem)
I do not need or want to show any notifications to my user. And many users are not willing to give notifications permission because they assume they will start seeing notifications.
But I wish to push data to my web page from the server. The web page is active and in the foreground. This is the classic use case that Web Sockets were designed for.
I understand that I could write my own web socket server and somehow try to scale it, or go to some other third-party for an outsourced scalable web socket push solution.
But, isn't this is a very common "sub-use-case" of the messaging that Firebase Messaging is targeted towards? Therefore shouldn't Google support this use case? I can't see any fundamental technical show-stoppers, but since Google is so smart, please do enlighten me if I am missing something on why this cannot or should not be done.
Original StackOverflow Question Text:
I don't need background notifications or service workers. All I want is to send data to the web page when it is currently loaded and in the foreground.
Websockets do not need any permission but they need a websocket server and maintenance. It is difficult or expensive to scale it.
Firebase solves the problem fundamentally but I don't see why it must require a user to give notifications permission even though I only want to push data when the page is loaded; not in the background.
The problem is that Firebase Messaging is only using 1 method to deliver notifications. That is the Push API specification spec, and that specification (wrongly and unfortunately) does not allow a service worker to receive messages without the user allowing an unrelated permission to show notifications.
The fix would be for the Firebase Messaging team to provide a different way to deliver messages to active web pages -- long polling, or websockets.
But it would be extra work for them, and may be not enough people are requesting it.
It's to protect the user's preferences about what your app is allowed to do. The way push messaging works on browsers is by using a service worker. Even though you say you don't need a service worker, you are actually making using of it when using Firebase Cloud Messaging in your app.
Given that, the prompt is necessary because the browser doesn't know what you intend to do with that push message. If the user doesn't trust your app, they should have the right to limit what it can actually do, especially when they're not using your app. Mobile operating systems (iOS, Android) are the same way.
Related
Update: Google Bug Report Description
(as suggested by google dev advocate in comments on answer 1, filed a bug report; updating the content here since it more succinctly and precisely describes the problem)
I do not need or want to show any notifications to my user. And many users are not willing to give notifications permission because they assume they will start seeing notifications.
But I wish to push data to my web page from the server. The web page is active and in the foreground. This is the classic use case that Web Sockets were designed for.
I understand that I could write my own web socket server and somehow try to scale it, or go to some other third-party for an outsourced scalable web socket push solution.
But, isn't this is a very common "sub-use-case" of the messaging that Firebase Messaging is targeted towards? Therefore shouldn't Google support this use case? I can't see any fundamental technical show-stoppers, but since Google is so smart, please do enlighten me if I am missing something on why this cannot or should not be done.
Original StackOverflow Question Text:
I don't need background notifications or service workers. All I want is to send data to the web page when it is currently loaded and in the foreground.
Websockets do not need any permission but they need a websocket server and maintenance. It is difficult or expensive to scale it.
Firebase solves the problem fundamentally but I don't see why it must require a user to give notifications permission even though I only want to push data when the page is loaded; not in the background.
The problem is that Firebase Messaging is only using 1 method to deliver notifications. That is the Push API specification spec, and that specification (wrongly and unfortunately) does not allow a service worker to receive messages without the user allowing an unrelated permission to show notifications.
The fix would be for the Firebase Messaging team to provide a different way to deliver messages to active web pages -- long polling, or websockets.
But it would be extra work for them, and may be not enough people are requesting it.
It's to protect the user's preferences about what your app is allowed to do. The way push messaging works on browsers is by using a service worker. Even though you say you don't need a service worker, you are actually making using of it when using Firebase Cloud Messaging in your app.
Given that, the prompt is necessary because the browser doesn't know what you intend to do with that push message. If the user doesn't trust your app, they should have the right to limit what it can actually do, especially when they're not using your app. Mobile operating systems (iOS, Android) are the same way.
I am coding a vue.js app using web pushes with Firebase Cloud Messaging and I wondered if it was possible to send a web push to a user and in case the user was offline, to somehow store it for later display when the user opens the app again. Is there a principled approach to this problem, i.e. managing web pushes when the end user is offline?
The reason I am asking this is that, so far, all the web push notifications I've committed to FCM server with tokens of offline clients (i.e. desktop browsers) went into oblivion. To be sure, FCM didn't try pushing the notification again when the clients went back online.
For this reason I am considering coding a self-made dispatcher to manage web push for offline clients, but I need to make sure my efforts are worth it.
updated: I am now able to display notifications sent to an offline client after coming back online using appropriate time_to_live values. However, only the latest notification is displayed. How is there any specific reason why?
FCM's default behavior is exactly like that. From the docs:
If the device is not connected to FCM, the message is stored until a connection is established (again respecting the collapse key rules). When a connection is established, FCM delivers all pending messages to the device.
I'm planning to add push notifications to my web app.
As far as I understand it, to push notifications to my users, I can either use a web push library and deliver the notifications directly, or use a push notification service such as OneSignal, Firebase Cloud Messaging, or Batch.com.
From what I understand, these services offer a one-stop solution to deliver notifications not only as Web Push, but also to iOS and Android apps.
If I'm focusing only on Web Push for now, is there any advantage I should be aware of, to use one of these services over a web push library directly?
Web Push is a standard which is still under development and subject to change. Also browser support is quite limited at the moment (see https://caniuse.com/#feat=push-api).
The advantage is: you have one API to rule all the supporting platforms (including desktop).
Disadvantage is: You have to be aware that not all platforms support the standard.
Using a notification SaaS solution to handle notifications enables you to handle all platforms. Sending out a notification from your backend will be a single call to your notification SaaS service, but you still have to be aware, when you want to have native notifications on Android, iOS and the browser, you will have to handle the integration of those platforms differently in your client apps (see example here using Google Cloud Message integration in an Android App: https://firebase.google.com/docs/cloud-messaging/android/client).
So your decision should be based on which platforms you have to support.
- If you get away with supporting Chrome, Firefox and Edge browsers on non-iOS-Devices (or handle iOS Notifications differently), you can use Web Push.
- Otherwise i would choose a Notification SaaS Solution.
The most important point for me personally when doing your own implementation is that you control everything. This means that your notifications don't fail when AWS loses a region or pricing changes and you can't afford it any more. Not any provider can ban you because of the content you distribute or the complaints from users. You can implement your own logic for showing the notifications on the front-end, like stacking them or having your own segmentation rules (paying users versus free tier, for instance). I'm not even speaking of the custom subscription UI. No weird copyright in your messages.
From what I understand, these services offer a one-stop solution to deliver notifications not only as Web Push, but also to iOS and Android apps.
When you've got the server logic to process the app events and send notifications in place, it shouldn't be really hard to extent it do work with mobile push notifications. The only thing that changes is the way you subscribe devices.
And the last, but not the least - it's fun to develop. This is more of a personal matter, I guess, but I like learning new thing :)
Hope that helps you to make a decision.
you can implement push notification to your website without using third-party libraries. You have required to get subscription token from the client and store this subscription token onto the server (Inside database). After when you want to send a push notification to the user then you have to just call endpoint (endpoint is mentioned in subscription token). That's it.
Due to security risk and managing subscription tokens, developers prefer to use firebase, AWS push notification or onesignal.com services. These services are optional you don't need at all.
Read links introduction to push notification and also the same lab code examples. Later I will update with simple working code for further reference to your question.
It depends on what you want. It‘s not possible to use iOS Safari for Web-Push. For notifications to iOS you have to use a service or build your own app.
I use Pushover for notifying myself from Scripts and Software. That may or may not be a solution depending on how much users you have, how many notifications you send and how willing your users are to use a web app like Pushover (or an app on iOS).
A service will keep notifications going when things change. So it should be less maintenance for you.
If you want to target iOS visitors also, this is not possible, as web push notifications are not supported by iOS.
To circumvent this, you need to use a third party service like Wise Notifications.
The alternative is to build an iOS app and send native push notifications.
We need to develop something similar to OneSignal (only web, no native apps) for private use. Where can we start? Is there some open source project we can use?
Each browser implements their own Push Service, so using a private/custom Push Service necessitates re-creating (at least portions of) the Push & Service Worker API's to achieve similar behavior client-side. Google has a nicely-written high-level overview; see the "Who and What is the Push Service?" section of Step 2. It's also worth noting that while the Push Service itself may be created, you will lose the functionality the browser provides the web app (e.g. waking the service worker on receiving a notification, even if the web app isn't in the foreground), because the browser will only be looking to its own Push Service.
Outside the browser (e.g. an Electron app), you will still need to re-create (portions of) the Push & Service Worker API's to achieve similar behavior client-side. In this case, you're likely still better off using a native Push Service for the target platform, if available.
If content privacy is the ultimate goal: the WebPush protocol provides a means of encryption between the client and application server, so the Push Service can't read the notification content. This, combined with the acceptance of a standard Push API, makes using a 3rd party Push Service allowable for most scenarios, and trivial compared to building everything from scratch.
However, if you absolutely need to make a custom Push Service, Mozilla's Push Service is the only fully open-source solution I've found. It may not be exactly what you need "out of the box", but may be close. Only the client and admin SDK's are open-source for Firebase, so far.
I have created a mobile app for Android and iOS using Phonegap Build. Last year I had nearly finished writing code to use GCM (Google Cloud Messaging) for remote push notifications - which can go out via Apple's APNS too - but the project was shelved.
This year the project is resurrected and I find Google has changed everything to Firebase (FCM). I then read some enticing things about Amazon SNS handling notifications. Just when I started to think SNS might be a better option, I noticed you still have to set up GCM/FCM anyway, and pass all those details to SNS.
So is there any benefit to using SNS when I've got to do the full FCM setup as well?! Both services seem to offer the same features: interact with APNS if required, subscribe to topics, provide you with a nice API/SDK, etc. The app code, and the server-side code would be no simpler, as far as I can see. Why add another layer (SNS) on top of FCM?
(I'm trying not to let this be an opinion-based question: I want to know whether SNS is saving me any effort, giving me any advantage, or adding any features that FCM does not have.)
Just some thoughts.
If you are already using some mobile AWS SDK, then it's more convenient to use it for SNS too.
That also helps keep your app smaller.
And you're happier as a developer since API calls are somewhat unified.
If your backend is hosted on AWS infrastructure you can use IAM roles for EC2 instances (also Lambdas etc.) to make those call without access key/secret key.
You get metrics in your CloudWatch.
But Firebase Cloud Messaging is free :)
Let's answer a few questions first.
1.Do you want to develop, maintain and run the code to talk to GCM?
2.Do you wish to do the same for another platform (iOS, Kindle Fire), if you choose to develop your app for other mobile platforms.
3.Do you want to manage change of registration_id's by yourself?
4.Do you care if a notification is delivered to your users a few milliseconds later?
If you answered NO to any of the questions above, I recommend using SNS to deliver push notifications to iOS, Android and Kindle Fire devices.
SNS talks to GCM to deliver notifications to android devices. Here is what SNS can offer you.
Simple API to send notification to heterogeneous platforms.
Manages application registration_ids. As a developer you don't have to worry about change of registration_ids.
Scales really well. You don't have to worry about managing infrastructure if your app becomes super popular.
Can tolerate GCM downtime & throttling.