Firebase Messaging Service 能否成为 Websockets/服务器发送事件的可扩展替代品？

Question

我正在开发一个 web 应用程序，目前我的应用程序服务器使用服务器发送事件来维护与用户的连接，以有效地将新消息和其他事件等内容推送给他们，而无需他们不断轮询服务器来询问。

我正在寻找一种实现推送通知的方法，以便当用户位于单独的选项卡中时，或者当用户在手机上运行通知并且将 Chrome 最小化时，我可以使用通知 Web API向用户发送通知。

经过一番研究，Google Cloud Messaging 似乎已被 Firebase Cloud Messaging 取代，这是推荐用于传递推送通知的服务。看起来它的工作原理是让用户与 Firebase 服务器保持持久连接，并且您的个人应用程序服务器将请求发送到 Firebase，以便它们传递给用户。

我的问题：这是否减轻了实现和维护 SSE / WebSocket 服务器的需要？我想知道是否不能只通过 FireBase 转发所有事件并通过他们的服务将它们传递给用户。也就是说，我将有两类消息均从 Firebase 发送：

一种是典型的“通知”，由用户解释（例如新消息），并且需要通知 API 的本地权限。另一种类型是其他不需要通知的“实时”更新（例如正在编辑的消息，或“用户正在输入消息”提示）

这种事情是否可能/推荐，或者我的理解在某些方面存在缺陷？

Answer 1

您所描述的任何内容似乎都不超出 FCM 的功能。

看起来它的工作原理是让用户与 Firebase 服务器保持持久连接

事实上，这不是“用户”。它是设备提供的消息传递基础设施。对于 Android，消息通过 Google Play 服务进行路由，该服务在后台作为特权进程运行。对于 iOS，消息通过 Apple 的 APNS。这些组件维护各自服务的开放套接字，它们比应用程序自己管理套接字更有效，因为应用程序无法无限期地在后台管理套接字 - 操作系统会在一段时间后将其关闭。这意味着应用程序可以在消息发送后立即唤醒并接收消息。