具有从服务器到客户端的主动推送通知的 REST API [英] REST API with active push notifications from server to client

问题描述

我正在开发一个 Xamarin 应用程序，该应用程序使用用 Python 烧瓶编写的 REST API.

i am working on a Xamarin application that consumes a REST API written in Python flask.

Xamarin 应用程序提供虚拟购物清单，用户可以在其中协作购买共享清单上的商品.

The Xamarin application offers virtual shopping lists where user can collaborate on buying stuff they have on a shared list.

为了改善用户体验，我希望能够主动通知用户列表中已完成的项目.

To improve the user experience, i want to be able to actively notify the user about finished items on the list.

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

Notifications are stored by the API in a relational database and have a flag indicating if the user received the notification already.

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

The API has an endpoint GET /users/:user_id/notifications/ that queries the database for notifications and returns a JSON response with those.

• 实施起来相当简单

• 同步轮询会产生大量的 http 请求

• synchronous polling creates a huge amount of http requests

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

API service remains stateless, making a horizontal scaling with a loadbalancer easier

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

The API has an endpoint POST /users/:user_id/notifications/register which creates a websocket connection between client and API.

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

The connection is stored to a global array in which each entry maps a client id to a websocket connection.

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

When a new notification is created, the endpoint makes a lookup in the connection dictionary by comparing the owner id of the notification with the dictionary entries. The notification is sent to appropriate user through the websocket.

通知像第一种方法一样存储在数据库中.

Notifications are stored in the database like in the first approach.

当用户调用端点时，将首先建立新的 websocket 连接，成功后 API 将所有未见通知从数据库发送给用户.

When a user calls the endpoint, a new websocket connection will be established first and upon success the API sends all unseen notifications from the database to the user.

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

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

API 使用 RabbitMQ 服务向客户端发送通知.每个客户端都使用订阅自己的通知队列来防止消息的广播.

The API uses a RabbitMQ service to send notifications to the client. Every client uses subscribes to his own notification queue to prevent the broadcasting of messages.

• API 保持无状态

• 当用户离线时需要将通知重新发送到交易所

• Notifications needs to be resend to the exchange when a user is offline

队列数量急剧增加

RabbitMQ 服务的额外费用

Additional costs for RabbitMQ service

当许多用户同时在线时，RabbitMQ 服务的临时负载很高

High temporary load on the RabbitMQ service when many users come online in the same time

听听别人的意见会很有趣.

It would be interesting to hear the opinion of others.

我相信从后端服务向客户端主动分发通知是一个非常常见的用例.

I believe the active distribution of notifications from backen services to clients i a very common use case.

最好，

推荐答案

我会使用 RabbitMQ 并使用将它们作为推送通知转发的事件.这将在用户未主动连接到网站时起作用，并增强与每个用户体验的互动，当收到通知时将返回网站了解更多信息，请参见 如何使用 Flask 后端设置基本的 Web 推送通知功能 或 如何在 ASP.NET Core 中向浏览器发送推送通知 或 使用 Spring Boot、Angular 和Firebase Cloud Messaging 这样RabbitMQ 就不会等到用户重新上线.如果用户在线，您可以通过 WebSockets 和负载均衡器(如 NGINX)将通知直接转发到 Xamarin 应用程序可以以优化的方式处理许多 WebSocket.来自客户端的同步 API 轮询是不太受欢迎的方式，因为它在没有任何更改的情况下使用请求使网络服务器过载.

I would use RabbitMQ and consume events forwarding them as push notifications. This will work while the user is not actively connected to the website and enhance the engagement with each user experience that will return to the website when notified for more information see How to setup basic web push notification functionality using a Flask backend or How to send push notifications to a browser in ASP.NET Core or Sending Notifications with Spring Boot, Angular, and Firebase Cloud Messaging this way the RabbitMQ will not wait until the user is back online. If the user is online you can forward the notification directly to the Xamarin application via WebSockets and a load balancer like NGINX that can handle many WebSockets in an optimized way. Synchronous API polling from the client-side is the less preferred way since it overloads the webserver with requests while nothing was changed.

这篇关于具有从服务器到客户端的主动推送通知的 REST API的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！