2

We tested the fluid framework with minimal requirements. Everything works fine in the demo application. https://github.com/microsoft/FluidExamples

questions:

  1. How does the Fluid framework work offline?
  2. Our backend is written in asp.net core. The server side of the fluid framework is written in node.js. How to integrate the asp.net core backend with the fluid service to get the latest document state? Need to write a driver for a Fluid service?
dilshod
  • 91
  • 1
  • 3

1 Answers1

4
  1. Offline.

Offline is an interesting topic for CRDTs generally. The Fluid Framework handles intermittent (short) offline scenarios well as long as all the connected clients have the metadata necessary to merge the change in. When the user makes changes, she does so with respect to a minimum sequence number (MinSeq.) If the her offline changes get added to the total order broadcast such that they are above her change's MinSeq, they will be merged with no additional handling.

MinSeq deserves a whole post, but it's the sequence number beneath which all connected clients can garbage collect the metadata necessary to merge changes. Therefore, as long as every client has that metadata, even if you were offline, the merge is easy.

For longer offline scenarios, the reconnecting client could request to lower the MinSeq (probably to the last MinSeq of the offline client.) All clients would then fetch the ops since the requested MinSeq and recreate the metadata. At this point, new changes could easily go in as we have mimicked the scenario where the new changes are above the minimum sequence number.

This could cause temporary perf & memory issues, but hasn't been a problem in reasonable experiments. I don't believe this feature is currently implemented in the Fluid Framework code base, but has been designed as above. (A PR on this topic would be very interesting!)

For even longer offline scenarios, you would probably need a three-way merge. For example: Two users open a document. User A goes on an airplane (loses internet) and writes Macbeth and user B writes Pride & Prejudice, what is the expected behavior when user A rejoins the session? These are entirely incompatible document states, so we'd need to present the users with a dialogue of some sort.

This is not implemented, but we have discussed some of the framework ergonomics of handling the three-way merge (i.e. what APIs would the app developer need.)

  1. Running Fluid in a non NodeJS backend

Document state is managed by the clients and is opaque to the server. There's a similar discussion in this issue. The easiest way to get Fluid Framework document state in an .NET backend would be to run a JS engine and open the Fluid document. You could also run a NodeJS micro service that hosts the Fluid document. This service would have a simple API surface that lets you fetch the data you need.

Sam Broner
  • 471
  • 2
  • 9