New open source framework from Microsoft. Uses neither OT or CRDT, but rather a new form of distributed data structures.
Fluid Framework is a collection of client libraries for distributing and synchronizing shared state. These libraries allow multiple clients to simultaneously create and operate on shared data structures using coding patterns similar to those used to work with local data.
Focused on the Client Developer: Applications built with Fluid Framework require zero custom code on the server to enable sophisticated data sync scenarios such as real-time typing across text editors. Client developers can focus on customer experiences while letting Fluid do the work of keeping data in sync.
Fluid Framework works with your application framework of choice. Whether you prefer straight JavaScript or a framework like React, Angular, or Vue; Fluid Framework makes building collaborative experiences simple and flexible.
Based on our two design principles of “Keep the Server Simple” and “Move Logic to the Client”, the majority of the Fluid codebase is focused on building Containers.
Fluid abstracts the networking and backend layers so developers can focus on building an user experience by only thinking “local”. There isn’t a centralized canonical data truth to check against anymore, instead all connected users have the data locally and all these users always eventually end up with the exact same data. This “local” approach allows for a zero latency experience while keeping data consistent.
One way to work around the latency and some of the conflict resolutions challenges is to pretend that we don’t need to talk to a server and that all changes are local . This is the approach the Fluid framework chose. Fluid still needs to eventually have all collaborators agree on the current state of our object(s) and has to avoid all conflicts . For that, it relies on eventual consistency provided by distributed data structures .
Move in the right direction.
The best code is the one you do not need to read/write/run.
I see they move the server into the browser too.
Nice.
I built mindgraph 2 years ago that completely eliminated server side coding.
As a gesture to enterprise customers it still had a server and a database.
Neither of them needed to be changed to suit application needs.
Not only the logic but even the metamodel moved to the “client”.
Asking the right question:
What if the only thing you need is a Browser.
My goal has been to make it so.
Really don’t want to downplay the usefulness of Fluid — it genuinely seems awesome.
On Adam’s point (and others) I’m a bit confused. The more that I read, the older the architecture feels. I haven’t seen this done on the web as a service, but applying a total order to events, distributing them to a client that does state management separate from rendering feels like the distributed systems practices that originally lead to the development of OT.
Is it simple? Yes. Have we seen this kind of solution before? Yes. Is that good? Yes! Does it have tradeoffs versus OT, CRDTs, RAFT, an so on? Sure does. Is this a totally radical approach? I’m less certain.
This is to say that:
I’m SUPER happy about this as signal
Fluid solves real problems for that class of application
This a fairly battle tested architecture
It plays to MS’s strengths with things like Azure at its disposal
Hm. I haven’t looked at it closely enough to form my own opinion, but from what little I understand it relies on a centralized service to broker and distribute changes.
That’s fine, and it certainly seems like it may be an improvement over the status quo. The important question for fission is whether it solves enough of a developer’s problems to make it irrelevant that fission is better architected, I suppose, and whether Microsoft has enough trust from the world that people will adopt it.
How it works doesn’t really affect how it’s adopted, y’know?
