FluidFramework VS jsynchronous

Have you seen FluidFramework? It's open source (MIT): https://github.com/microsoft/FluidFramework

I think the first product they're building on it is Loop: https://www.zdnet.com/article/microsoft-introduces-loop-a-ne...

Full disclosure I work at MSFT and on the fluid framework.

If you are interested in this you may also be interested in the fluid framework, https://github.com/microsoft/FluidFramework

We use websockets and solve a lot of the state management problem called out here by keeping very little state on the server itself. The primary thing on server is a monotonically increasing integer we use to stamp messages, this gives us total order broadcast which we then build upon: https://en.m.wikipedia.org/wiki/Atomic_broadcast

Here are some code pointers if you want to take a look:

The map package is a decent place to look for how we leverage total order broadcast to keep clients in sync in our distributed data structures:

(Disclosure: Work at Microsoft, but I work in Azure and some open source stuff, not on or directly with Fluid/Office/etc.)

That's just a trademark clause for Microsoft logos and brands. The Fluid Framework itself is [MIT licensed](https://github.com/microsoft/FluidFramework/blob/main/LICENS...) and doesn't require exposing any of those logos/brands when you use it, so the framework itself is fairly open for usage.

I think the main thing that would slow down adoption for Fluid is that the only "production" backend is an Azure service, which isn't part of the open source Fluid Framework. [Other open source backends](https://fluidframework.com/docs/deployment/service-options/) aren't recommended for productions. Until there are some open source ones, I'd assume adoption will be limited to folks in the Azure ecosystem.

Within the context of the Microsoft-verse, Fluid Framework (https://fluidframework.com) is supposed to be solving similar problems in web apps, although I haven't personally played with it.

Microsoft recently open sourced fluid framework. It is a distributed, consensus based, real time collaboration framework written in typescript. Fluid would keep your clients synced up and your server code would only have to handle when someone hits submit. Fluid Framework

The official documentation and the github repository seem clear.

A data-synchronization library for Node.js

https://github.com/siriusastrebe/jsynchronous

Ever get tired of sending API requests and JSON payloads? Wouldn't it be cool if data just synced between server and client?

Jsynchronous lets you share deeply nested object/arrays between node.js and connected browsers – and any changes made to that variable.

For the very reasons listed in the article, I built:

https://github.com/siriusastrebe/jsynchronous

a library for keeping a javascript variables synchronized between Node.js servers and clients.

Websockets work great for message passing but it struggles with data structures more complicated than what JSON can represent. Jsynchronous syncs any javascript object or array with arbitrarily deep nesting and full support for circular data structures.

If a computer goes to sleep, or disconnects, websocket connections (and their underlying TCP connections) get reset so you lose any data sent while a computer is unavailable. Jsynchronous will re-send any data clients are missing.

There's also a history mode that lets you rewind to past states.

I recently built https://github.com/siriusastrebe/jsynchronous which uses event sourcing to synchronize javascript variables on the server with connected browsers.

You can also replay states using a special “rewind” mode, a core advantage of event sourcing.

Not for rust - for javascript: Take a look at this library: https://github.com/siriusastrebe/jsynchronous

Fullstack web developer, data visualization and real-time app specialist

I recently built and open sourced https://github.com/siriusastrebe/jsynchronous a real-time data sync library for javascript.

Location: Seattle, full time roles