目前，每当有新数据传入时，我正在使用 Socket.io / SignalR 从我的后端消息队列系统发出一个事件。这样我就可以在我的 React 应用程序中设置一个事件处理程序，并从事件处理程序中更新中继缓存。
它似乎不是最 Graphql ish 做事的方式，所以我玩了一下 RFC 之前的实时查询实现，您观察到响应式数据存储中的数据更改将其推送到 graphql 服务器，并进一步推送到客户端使用 websockets ......带有一些相当复杂的自定义代码......显然graphql 还没有准备好进行实时查询（不是轮询）
再往下几行说：
在构建基于事件的订阅时，确定什么应该触发事件的问题很容易，因为事件明确定义了这一点。事实证明，在现有消息队列系统上实现它也相当简单。
这引出了我的问题。当一个新事件传入您的后端消息队列应用程序并且您需要在 ui 中实时反映这些新数据时，您如何（以 graphql 方式）最好地触发 graphql 订阅 - 比如说每秒？我不是在谈论在前端/客户端中触发事件或像您在谈论订阅时通常看到的那样每隔 x 秒轮询一次。
不确定它是否相关，但我使用 Relay Modern 作为我首选的 graphql 客户端。
如果我得到一点帮助来了解如何在没有突变的情况下触发/调用订阅，这里有一些想法可能会奏效。
后端工作人员/消息队列“A”接收带有一些设备数据的新传入事件。它使用 SignalR 或其他 pubsub (redis/socket.io/?) 通知 graphql 服务器“B”（订阅事件）有新事件发生。然后，graphql 服务器触发/执行订阅，前端反应中继应用程序“C”自动更新，因为它定义了中继订阅。这将是理想的，对吧？但是如何在graphql服务器上触发订阅？
只需使用 Socket.io/SignalR 从后端工作人员/消息队列“A”对传入数据发出事件，订阅并处理前端“B”中的事件，然后从 Socket.io/SignalR 事件中以编程方式调用订阅处理程序（如果这样的话，直接调用订阅，甚至是可能的？）。但是，使用订阅而不是纯 Socket.io/SignalR 的唯一改进是我已将中继缓存/存储的更新从处理程序移至订阅。如果有的话，也不是很大的改进。但是缓存/存储的手动更新确实很麻烦，虽然不是那么难：/
人们如何使用信号器处理实时流式传输（设备）数据，为什么所有实时文章/示例都只是重复相同的旧简单聊天应用程序，其中用户界面只是在用户进行点击事件后更新？graphql 是否还不适合实时处理频繁传入的设备数据流？我明白为什么实时查询在自己实现它们之后被延迟了，但是没有它们，实时数据更新并将其从服务器推送到前端？