我正在开发一个 Web 应用程序，目前我的应用程序服务器使用服务器发送事件来维护与用户的连接，以有效地将新消息和其他事件等内容推送给他们，而无需他们不断轮询服务器询问。
我正在寻找一种实现推送通知的方法，以便我可以使用通知 Web API 在用户位于单独的选项卡中时向用户传递通知，或者当他们在手机上运行通知并且将 Chrome 最小化时。
经过一些研究，看起来Google Cloud Messaging已被Firebase Cloud Messaging取代，这是推荐用于发送推送通知的服务。看起来它的工作原理是让用户保持与Firebase服务器和您的个人应用服务器向Firebase发布请求以将其传递给用户。
我的问题：这是否减轻了实现和维护SSE/WebSocket服务器的需求？我想知道我是否不能通过FireBase转发所有事件，并通过他们的服务将它们传递给用户。也就是说，我将有两类消息都从Firebase发送：
一种是典型的"通知"，它由用户解释为这样(例如新消息(，并且需要通知 API 的本地权限。然后另一种类型是不需要通知的其他"实时"更新(例如正在编辑的消息或"用户正在键入消息"提示(
这种事情是否可能/推荐，或者我的理解在某些方面有缺陷？
您所描述的任何内容似乎都超出了 FCM 的功能范围。
看起来它的工作原理是让用户保持与Firebase服务器的持久连接
实际上，它不是"用户"。 它是设备提供的消息传递基础结构。 对于Android，消息通过Google Play服务路由，该服务在后台作为特权进程运行。 对于iOS，消息传递通过Apple的APNS。 这些组件维护其各自服务的开放套接字，它们比应用自行管理套接字更有效，因为应用无法无限期地在后台管理套接字 - 操作系统将在一段时间后将其关闭。 这意味着应用可以在发送消息后立即唤醒并接收消息。