3rd-Party API 的可扩展/负责任的轮询

Question

我维护了一个应用程序，它充当公开 API 的社交媒体网站的包装器。我的应用程序会跟踪每个用户发布的特定帖子，并报告每个帖子的最新活动。

我目前正在对应用程序进行重构，并希望添加实时更新功能（即，如果用户保持页面打开，它将在适用时更新跟踪帖子的新更改）。但是，我不确定执行此类操作的最佳实践。

就从我的后端获取数据到我的前端代码而言，像 SignalR 或其他 websocket 框架之类的东西会很棒，但是第 3 方 API 只是公开了一堆 REST 端点。因此，我的后端大概会定期轮询 3rd-party API 以获取每个帖子的数据。

但是，无论我如何考虑尝试实现这一点，随着我的用户数量（以及因此跟踪的帖子数量）的增长，它似乎非常不可扩展，尤其是在我对第三方资源的使用方面。 （当用户首先加载应用程序时，我已经偶尔不得不限制我的请求。）

是否有最佳实践可扩展/负责任的方式来以平衡资源使用和用户体验的方式检索此类远程静态数据？

Answer 1

你还没有提到你喜欢使用什么堆栈，所以我将不得不笼统地回答这个问题。

如果您打算与之集成的系统仅支持 REST 接口，那么轮询确实是您需要做的。然而，为了使其可扩展，我会将数据检索与提供实时更新的流程分开。那么两个主要组成部分是：

• 轮询 REST Web 服务并更新您的数据存储
• 使用实时引擎从数据存储区发送数据

您正在检索的数据的性质、您需要/打算如何处理数据以及您的目标平台是什么，这些都将决定合适的堆栈是什么。检索数据的解决方案也可能与您设计的从数据存储区发送数据的解决方案完全不同。