Difference between Fluid-Framework and Signal-R

Question

Question: Microsoft recently released the Fluid-Framework on github, How can/ steps to replace Signal-R with MS Fluid-Framework and what would be the key differences?

Use Case: Fluid seems to support collaboration and data sync for Mermaid etc diagramming/Flowchart, which was a core use case. So, when I started trying to replace Signal-R with Fluid-Framework, I quickly realized both the docs. & guidance on this is missing.

Some confusion for me, I would appreciate some information:

• The client-server is missing on their home page and confusing me. For e.g. I wanted to configure the sync data, how often, fall back storage, custom claims in the container, port info, bind attributes in the Action/API signature, but this data in the samples/help is not strongly typed? import { DataObject, DataObjectFactory } from "@fluidframework/aqueduct"; Just need more strongly type samples on the server side wire up.

• Fluid Container: Transition or Query information for the state of active nodes, next nodes from the mermaid chart is also not clear, how do I get this

Missing documentation

Answer 1

SignalR is an excellent library for sending messages to and from the client. It would be reasonable for someone to write a driver that replaces the socket.io driver, another WebSocket implementation, in Fluid Framework.

Fluid Framework is not a drop-in replacement for WebSockets, Socket.IO, or SignalR. The app would probably have to move more of the client state into Fluid distributed data structures

Developers that use SignalR and WebSockets are often used to power Last Write Wins data structures e.g. a message is sent over a WebSocket that updates a value in a map on the client. In simpler scenarios, the message sent over WebSocket, could just be a notification e.g. you have mail, emit an alarm.

Fluid is about maintaining state, not about transmitting messages. While LWW data structures are included in Fluid, some data structures require more complex state management. Strings and sequences aren't last write wins.

How would a last write wins algorithm handle two users simultaneously editing a string?

Starting state "Hello World";
Alice adds "!" at the end;
Bob adds "?" at the end;

You might have odd behavior resulting in "Hello World?" or "Hello World!"

Fluid orders Bob's change and Alice's change through the Fluid service. The merge tree data structure then has a reproducible merge algorithm for applying those ordered changes. Ultimately the string would read "Hello World?!"

Although simple examples may be easy to implement, especially LWW, more complex examples are a challenge. OT & CRDTs are two existing ways of handling state replication. Much of Fluid's initial value proposition is around maintaining complex state on your behalf.