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.
See Question&Answers more detail:
os 与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…