Firebase消息传递服务可以作为websockets /服务器发送事件的可伸缩替代吗？

Question

我正在开发一个webapp，目前我的应用服务器使用server事件来维护与用户的连接，从而有效地将新消息和其他事件等事情推送给他们，而不需要他们不断轮询服务器的请求。

我正在寻找一种实现推送通知的方法，这样我就可以使用通知Web将通知传递给用户，无论是在单独的选项卡中，还是当用户在手机上运行时，并且Chrome最小化了。

经过一些研究后，看起来Google消息传递已经被Firebase消息传递所取代，这是推荐用来传递推送通知的服务。看起来，它的工作方式是让用户维护一个持久连接，Firebase服务器和您的个人应用服务器向Firebase发送请求，以便将请求传递给用户。

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

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

这类事情是可能的/推荐的吗?还是我的理解在某些方面有缺陷？

Answer 1

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

它看起来是通过让用户维护一个持久连接Firebase服务器来工作的

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