.stl 转为.vtk_Stl.Fusion与SignalR有何相似之处？

.stl 转为.vtk

Even though both libraries are targeting similar problems (they help to write real-time apps faster), they do this quite differently:

即使这两个库都针对类似的问题(它们有助于更快地编写实时应用程序)，但它们的执行方式却大不相同：

• SignalR offers an API helping to deliver server-side notifications to the clients (and vice versa). It’s ~ a layer above WebSockets,that helps your server-side code to track clients, group them, and send messages to either individual clients, a group of them, or all the clients connected to hub (~ SignalR server). Besides that, SignalR has clients written in several languages, and I guess they implement connection resilience and some of other must-have features any production app needs.

  SignalR 提供了一个API，可帮助向客户端传递服务器端通知(反之亦然) 。 它是WebSockets之上的〜层，可帮助您的服务器端代码跟踪客户端，对其进行分组并向单个客户端，一组客户端或连接到集线器(〜SignalR服务器)的所有客户端发送消息。 除此之外，SignalR还用多种语言编写了客户端，我想他们实现了连接弹性以及任何生产应用程序需要的其他一些必备功能。

• And Stl.Fusion, even though it also uses WebSockets, solves a very different problem: it lets you find out when a piece of data you requested earlier gets changed. Fusion’s main selling points are:

  而且，即使Stl.Fusion也使用WebSockets，它也解决了一个非常不同的问题： 它使您能够发现何时更改了您先前请求的数据 。 Fusion的主要卖点是：

  a) it largely automates this complex task by

  a)通过以下方式很大程度上自动化了这项复杂的任务

  tracking dependencies between such pieces of data

  跟踪这些数据之间的依赖关系

  b)

  b)

  it is capable of doing this even if the data you consume is remote — and that’s exactly what enables Fusion-based real-time UI to work. Fusion offers a “replica service” abstraction, which looks identical to a similar server-side service, but instead of computing the output of any of its methods locally, it invokes a remote counterpart that does this and wires up everything needed to invalidate the replica as soon as matching remote value gets invalidated.

  即使您使用的数据是远程数据，它也能够执行此操作 -这正是使基于Fusion的实时UI能够正常工作的原因。 Fusion提供了一个“副本服务”抽象，看上去与类似的服务器端服务相同，但是它没有在本地计算其任何方法的输出，而是调用了一个远程副本来执行此操作，并连接使副本无效的所有内容一旦匹配的远程值失效。

This was the main part of the answer. If you want to learn the details — e.g. what Fusion really changes in comparison to SignalR— read further.

这是答案的主要部分。 如果您想了解详细信息，例如Fusion与SignalR相比真正改变了什么，请进一步阅读。

* Real *实时聊天应用中的SignalR (SignalR in *Real* Real-Time Chat App)

Imagine you’re building a real-time chat app, and SignalR is the library you want to use to deliver real-time updates to every client. Here is how a typical “change-to-update” sequence involving SignalR looks like:

假设您正在构建一个实时聊天应用程序，SignalR是您要用来向每个客户端提供实时更新的库。 这是涉及SignalR的典型“更新更新”序列的样子：

• One of the clients makes an API call (or uses SignalR to message server) to post a new message to channel C.

  客户端之一进行API调用(或使用SignalR到消息服务器)以将新消息发布到通道C。

• The server persists the message into the DB and responds ~ “200 OK” to the original client. If it wouldn’t be a real-time app, that’s where we would stop.

  服务器将消息持久保存到数据库中，并对原始客户端做出〜200 OK响应。 如果它不是实时应用程序，那就是我们将要停止的地方。

• But in our case we have to do more — now the server has to notify other clients about this change. This looks like a simple problem at glance — just broadcast the message to everyone connected! That’s the approach shown in almost every SignalR sample. Why? Keep reading.

  但是在我们的情况下，我们必须做更多的工作-现在服务器必须将这一更改通知其他客户端。 乍看之下，这似乎是一个简单的问题- 只需将消息广播给所有连接的人！ 几乎每个SignalR样本都采用了这种方法。 为什么？ 继续阅读。

• Ideally, you want to notify just the clients that are interested in this update — the ones keeping channel C open (so they see the chat itself) or “pinned” (so they see the number of unread messages), or maybe looking at the settings page of this channel, which also displays the number of unread messages there.

  理想情况下，您只想通知 对此更新 感兴趣 的客户端 -保持通道C打开(以便他们看到聊天本身)或“固定”(以便他们看到未读消息的数量)的客户端，或者查看此频道的“设置”页面，该页面还会显示该频道中未读邮件的数量。

• SignalR’s “groups” feature is designed to address almost exactly this problem. All you need is to dynamically add/remove users to a group you may internally call as “seeingChannel(C)”. Once you have this, you can broadcast a message to this group.

  SignalR的“组”功能旨在解决几乎所有此问题。 您需要做的就是动态地将用户添加/删除到您可以内部称为“ seeingChannel (C)”的组中 。 获得此权限后，您可以向该组广播消息。

• But if you think what’s required to implement this “dynamic add/remove” behavior, you may quickly conclude it’s totally not as easy as it seems, because you have to do this based on the client-side UI state — in other words, now you have to notify server each time client opens or closes settings page of channel C to let it decide whether the client still has to be a part of “seeingChannel(C)” or not, and so on. And it’s complex — e.g. the fact client closed channel C settings alone obviously doesn’t mean you can remove the client from “seeingChannel(C)” group.

  但是，如果您认为实现这种“动态添加/删除”行为需要什么，您可能会很快得出结论，这并不像看起来那样简单，因为您必须基于客户端的UI状态 (换句话说，现在)您必须在每次客户端打开或关闭通道C的设置页面时通知服务器，以使其决定客户端是否仍必须是“ seeingChannel (C)”的一部分，依此类推。 这很复杂-例如，仅客户端关闭通道C设置这一事实显然并不意味着您可以从“ seeingChannel (C)”组中删除该客户端。

• Worse, typically you want to retain the client-side UI state on reconnection / server restarts. And SignalR state (groups, etc.) doesn’t “survive” neither restarts nor connections to another server. So once this happens, you’ll need something allowing server and client to negotiate the groups to subscribe to.

  更糟糕的是， 通常您希望在重新连接/服务器重启时保留客户端UI状态 。 而且SignalR状态(组等)不会“存活”，既不会重启也不会与另一台服务器建立连接。 因此，一旦发生这种情况，您将需要允许服务器和客户端协商要订阅的组的内容。

• Oh, and what about the messages that could be posted while you were reconnecting? One way to address this is to re-request every piece of data you display (but you don’t want to lose what’s typed by user, right — i.e. you can’t simply refresh everything), another — to store the messages you send to every client & implement reliable delivery. In short, this is also something to think about.
  哦，重新连接时可以发布的消息又如何呢？ 解决此问题的一种方法是重新请求显示的每条数据(但您不想丢失用户键入的内容，对，即您不能简单地刷新所有内容)，另一种方法是存储发送的消息给每个客户并实施可靠的交付。 简而言之，这也是要考虑的问题。
• And that’s not the end: once you received the message on the client, you have to apply it to the UI state there, which typically means to dispatch through a set of reducers (if you use Redux) so that some of them will apply it to the corresponding part of the UI state, which in turn will make related UI components to re-render.
  但这还没有结束：在客户端上收到消息后，您必须将其应用到那里的UI状态，这通常意味着要通过一组化简器(如果使用Redux)进行分派，以便其中一些将应用它到UI状态的相应部分，这将使相关的UI组件重新呈现。

The gist: contrary to toy apps, the real-life SignalR application requires a fair amount of complex logic. If you want your chat app to be scalable like Slack, you need nearly what I wrote just to handle a single action — “MessagePosted”. And there are 10s of other actions — user joining the channel, leaving the channel, channel permissions changed, user presence messages, etc., and each one of them requires very similar handling.

要点：与玩具应用程序相反，现实生活中的SignalR应用程序需要大量的复杂逻辑。 如果您希望聊天应用程序像Slack这样可扩展，则几乎需要我编写的内容来处理一个动作-“ MessagePosted”。 还有十多个其他动作-用户加入频道，离开频道，更改频道权限，用户状态消息等，并且每个动作都需要非常相似的处理。

But if you think what you are really achieving by doing all of this, you’ll quickly conclude the only end result of your actions is that the client-side state (of every client) becomes consistent with the server-side state!

但是，如果您认为通过所有这些操作真正实现了什么，那么您将很快得出结论：您的操作的唯一最终结果是(每个客户端的)客户端状态与服务器状态保持一致！

In other words, SignalR, messaging, etc. — all of this isn’t essential to the problem you are solving. Your problem is to “replicate” the state changes happening on the server to every client that’s interested in this part of the server’s state.

换句话说，SignalR，消息传递等—所有这些对于您要解决的问题都不是必需的。 您的问题是将服务器上发生的状态更改“复制”给对服务器状态这一部分感兴趣的每个客户端。

And Stl.Fusion is designed to solve exactly this problem. Instead of making you to dynamically subscribe/unsubscribe every client to a fair number of SignalR channels, it does something similar completely automatically for you:

Stl.Fusion旨在解决此问题。 与其让您动态地向每个客户端订阅/取消订阅相当数量的SignalR频道，不如让您完全自动地执行类似的操作：

• When you invoke a replica service on the client, it automatically subscribes to the invalidation of the result

  当您在客户端上调用副本服务时，它会自动订阅结果无效

• Since server-side Fusion tracking works the same way on the client-side, the client is free to compose its own UI state relying on multiple calls to multiple replica services. Technically, it can even expose its own services to other clients (or to the server) as replica services!
  由于服务器端Fusion跟踪在客户端的工作方式相同，因此客户端可以自由地依靠对多个副本服务的多次调用来编写自己的UI状态。 从技术上讲，它甚至可以将自己的服务作为副本服务公开给其他客户端(或服务器)！

• All of this allows you to precisely know when any piece of data you have becomes obsolete/invalidated (likely changed).

  所有这些使您可以精确地知道何时您拥有的任何数据过时/失效( 可能已更改 )。

• Finally, every IComputed<T> (the “envelope” for any value Fusion tracks, including remote replicas) is “renewable” — it allows you to request its most up-to-date version at any moment, so you’re free to update any piece of data you have w/o any hassle. In particular, you don’t need to remember the original call arguments, etc. — this information is already there (but hidden, of course).

  最后，每个IComputed <T> (Fusion跟踪的任何值的“信封”，包括远程副本)都是“可更新的”-它允许您随时请求其最新版本，因此您可以自由地更新您没有麻烦的任何数据。 特别是，您不需要记住原始的调用参数，等等-该信息已经存在(当然是隐藏的)。

I highly recommend checking out Stl.Fusion Samples to see how this works in action, but overall, none of the issues I mentioned above are relevant there!

我强烈建议您查看Stl.Fusion示例以了解其工作原理，但是总的来说， 我上面提到的所有问题都与那里无关！

Besides that, Stl.Fusion provides:

除此之外，Stl.Fusion还提供：

• Connection resilience. Once the connection to Fusion Publisher is dropped, the remote Replicator will be trying to reconnect till it succeeds (FYI it publishes the status of each connection as IComputed too, so you can “observe” even it :) ). And once it succeeds, it will automatically re-subscribe to every replica it tracks, so if changes happened in between, you’ll learn about this, and if the replica was gone on server (e.g. due to timeout or server change), replica service on the client will request a new one — and all of this happens completely transparently for you!

  连接弹性。 断开与Fusion Publisher的连接后，远程复制器将尝试重新连接，直到成功为止(仅供参考，它也将每个连接的状态也发布为IComputed ，因此您也可以“观察”它：))。 并且一旦成功，它将自动重新订阅其跟踪的每个副本，因此，如果在两者之间发生更改，您将了解到这一点，以及该副本是否在服务器上(例如由于超时或服务器更改)客户端上的服务将请求一个新的服务- 所有这些对您来说都是完全透明的！

• Protocol abstraction API. Almost everything related to remote replicas is located in Stl.Fusion.Bridge namespace, and you might notice it’s a part of Stl.Fusion.dll, which doesn’t reference neither ASP.NET Core nor WebSockets. Internally Fusion assumes that all the communication channels are Channel<Message>, where Message is a base type for Fusion messages. The WebSocket-based Fusion client (and server as well) relies on Channel<T> “wrapper” over WebSocket — in other words, it’s just one of possible communication protocols, and likely we’ll add more of them in future — harder, better, faster, stronger :)

  协议抽象API 。 几乎所有与远程副本有关的内容都位于Stl.Fusion.Bridge命名空间中，您可能会注意到它是Stl.Fusion.dll的一部分，后者既没有引用ASP.NET Core也没有引用WebSockets。 在内部，Fusion假定所有通信通道都是Channel <Message> ，其中Message是Fusion消息的基本类型。 基于WebSocket的Fusion客户端(以及服务器)依赖于WebSocket上的Channel <T>“包装器”，换句话说，它只是可能的通信协议之一，并且将来我们可能会添加更多的此类协议，更好，更快，更强大:)

The gist is: (Stl.Fusion, SignalR) ~ (apples, oranges).

要点是： (Stl.Fusion，SignalR)〜 (苹果，橘子) 。

翻译自: https://medium.com/swlh/how-similar-is-stl-fusion-to-signalr-e751c14b70c3

.stl 转为.vtk