javascript - Firebase 消息服务能否成为 websockets/服务器发送事件的可扩展替代品？

Question

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

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

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

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

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

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

标签： javascriptandroidfirebaseweb-applicationswebsocket

Answer 1

您所描述的一切似乎都超出了 FCM 的能力。

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

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