如何从后端消息队列应用程序触发GraphQL订阅

当前，无论何时传入新数据，我都使用Socket.io / SignalR从后端消息队列系统发出事件。这样，我可以在React应用程序中设置事件处理程序，并从事件处理程序中更新中继缓存。

这似乎不是最常用的Graphql方法，所以我在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进行的唯一改进是，我将中继缓存/存储的更新从处理程序移到了订阅。如果有的话，没有太大的改进。但是手动更新缓存/存储确实很麻烦，尽管不是那么困难：/

人们如何使用Signalr处理实时流式传输（设备）实时数据，为什么所有的实时文章/示例都只是重复相同的旧的简单聊天应用程序，而ui只是在用户单击事件后进行更新？graphql是否还不适合实时处理频繁进入的设备数据流？我了解为什么实时查询在自己实施后会被延迟，但是如果没有实时查询，实时查询会将实时查询更新从服务器推送到前端吗？