Can Firebase Messaging Service be a scalable replacement to websockets / server sent events?

Question

I am developing a webapp and currently my app server uses Server Sent Events to maintain a connection to the user to efficiently push things like new messages and other events to them without them having to constantly poll the server to ask.

I'm looking for a way to implement Push Notifications such that I can use the Notification Web API to deliver notifications to the user either when they are in a separate tab, or when they have it running on their phone and they have Chrome minimized.

After some research, it looks like Google Cloud Messaging has been replaced by Firebase Cloud Messaging, and this is the recommended service to use to deliver push notifications. It looks like it works by having the user maintain a persistent connection the Firebase Servers and your personal app server posts requests to Firebase for them to deliver to the user.

My question: does this alleviate the need to implement and maintain an SSE / WebSocket server? I'm wondering if I can't just forward all my events through FireBase instead and have them be delivered to the user via their service. That is, I would have two classes of messages both sent from Firebase:

One would be the typical "notifications" which are interpreted as such by the user (such as a new message), and require local permissions for the Notifications API. And then the other type would be other "real-time" updates that wouldn't require a notification (such as a message being edited, or the "user is typing a message" prompt)

Is this sort of thing possible / recommended, or is my understanding flawed in some aspect of this?

Answer 1

Nothing you're describing seems outside of capabilities of FCM.

It looks like it works by having the user maintain a persistent connection the Firebase Servers

Actually, it's not the "user". It's the messaging infrastructure provided by the device. For Android, the message get routed through Google Play services, which runs as a privileged process in the background. For iOS, messges go through Apple's APNS. These components maintain an open socket to their respective services, and they're more effective than the app managing the socket on its own, because the app can't manage a socket in the background indefinitely - the OS will shut it down after some time. This means the app can wake up and receive messages soon after they're sent.