想象一下，我们想要为数千名用户提供一个 Web 应用程序。即使用户不主动刷新页面，页面上的信息也应该保持最新。目前，我们有两种方法来实现这一目标：
以下是一些想法：
我们想知道哪种解决方案可扩展性更好/值得推荐。
如果您有这样的权衡经验，如果您能分享一下那就太好了。
实时更新：GraphQL 订阅旨在为客户端提供实时更新。这对于需要在用户界面上反映即时数据更改的应用程序尤其有利。一位用户所做的更改可以立即被查看相同数据的其他人看到。
减少网络流量：订阅仅在发生实际更改时才发送数据，与定期查询相比，这可能会导致通过网络传输的数据更少。这对于移动设备或带宽有限的用户尤其重要。
复杂性：实现订阅可能比定期查询更复杂，因为它涉及在客户端和服务器上设置和管理 WebSocket 连接。服务器端处理订阅需要额外的基础设施，例如 WebSocket 服务器。
用户体验：订阅提供了更加无缝和交互式的用户体验，因为更新会实时推送到客户端。需要用户之间协作或沟通的应用程序可以从这种即时反馈中受益。
可预测的负载：由于请求是定期发送的，因此定期查询会在服务器上产生稳定的负载。这种可预测性可以使资源分配和扩展更加简单。
带宽消耗：与订阅相比，定期查询会消耗更多带宽，尤其是在频繁更新的情况下。但是，可以通过使用高效的缓存机制来减轻影响。
服务器效率：可以批量处理定期查询，可能允许服务器优化和批量请求。但是，如果太多客户端同时同步查询，则可能会导致性能瓶颈。
延迟：定期查询会在客户端上的数据更改和更新之间引入延迟。客户端可能要等到下一次查询才能反映最新数据。
关键数据与非关键数据：考虑对需要实时更新的关键数据使用订阅，对时间敏感度较低的数据使用定期查询。 这平衡了实时更新的好处和定期查询的效率。
可扩展性：根据应用程序的扩展要求，您可以对一部分用户（例如高级用户或活跃参与者）使用订阅，并依赖定期查询其他用户。
资源管理：无论采用哪种方法，监控资源利用率（包括内存、CPU 和网络使用情况）都至关重要。正确管理资源可确保最佳性能和可扩展性。
延迟分析：在延迟敏感的应用程序中，将更新通过订阅到达客户端所需的时间与定期查询引入的延迟进行比较。
负载测试：在各种场景中运行负载测试，以了解每种方法在不同级别的用户活动下的表现。
缓存：使用智能缓存策略通过最大限度地减少冗余查询或重复的订阅更新来减少服务器负载和带宽消耗。