具有从服务器到客户端的活动推送通知的REST API

Question

问题描述

我正在使用Xamarin应用程序，该应用程序使用Python烧瓶编写的REST API。

Xamarin应用程序提供虚拟购物清单，用户可以在其中进行协作以购买他们在共享清单上拥有的东西。

为了改善用户体验，我希望能够主动通知用户列表中的成品。

可能的解决方案：

从客户端进行同步API轮询

通知由API存储在关系数据库中，并具有一个标志，指示用户是否已经收到通知。

API具有一个端点GET /users/:user_id/notifications/，该端点在数据库中查询通知，并返回带有这些通知的JSON响应。

优势

• 实施起来很简单

问题

• 同步轮询会创建大量的http请求

• API服务保持无状态，从而使使用负载均衡器的水平扩展更加容易

API上的Websocket端点

API有一个端点POST /users/:user_id/notifications/register，该端点在客户端和API之间创建了websocket连接。

该连接存储到一个全局数组中，其中每个条目都将客户端ID映射到websocket连接。

创建新通知时，端点通过将通知的所有者ID与字典条目进行比较，在连接字典中进行查找。通知通过网络套接字发送给适当的用户。

通知与第一种方法一样存储在数据库中。

当用户调用端点时，将首先建立一个新的Websocket连接，一旦成功，API将把所有看不见的通知从数据库发送给用户。

优势

• API可以异步将通知推送给客户端

问题

• 当用户终止websocket连接时，他的词典条目将持续存在
• 为每个用户保留一个websocket连接将永久增加API的额外开销
• API的水平可扩展性更加困难，因为该服务不再不是无状态的（Websocket连接信息保存在
中

RabbitMQ

API使用RabbitMQ服务将通知发送到客户端。每个客户端都使用订阅者自己的通知队列来阻止消息的广播。

优势

• API保持无状态

问题

• 用户离线时需要将通知重新发送到交换处

• 队列数量急剧增加

• RabbitMQ服务的额外费用

• 当许多用户同时联机时，RabbitMQ服务的临时负载较高

最后一句话

听到别人的意见会很有趣。

我认为在一个非常常见的用例中，从后端服务向客户端的主动分发通知。

最好， D

Answer 1

对于提供JSON的API，我可以推荐另一种方法，称为GraphQL

它支持GraphQL API服务器（使用Web套接字）推送的订阅功能
如今，GraphQL被认为比RESTful API更好，因为它非常灵活，您只需一次查询就可以准确获取所需的数据。

Answer 2

Websocket 是不错的解决方案，您仍然可以在负载均衡器的帮助下进行扩展。在我看来，您可以尝试使用长轮询、简单的解决方案并保持请求-响应模式。有了任何 nio 支持，您都可以轻松实现它。有关更多信息，您可以阅读以下链接 https://ably.com/topic/long-polling 和谷歌以获取更多信息