I'm more than a little worried about the following all being `Coming Soon`:
- Cursors & carets
- Two way sync to your DB
- Video presence & calls
- both the Group and BinaryCoStreams
All of these are the key reasons I would be evaluating this framework to handle my data. All of these are not fully implemented yet.
It is these key topics of live reloading/updating data that make or break an app. In my opinion, if you haven't concretely solved these problems, you haven't really built a viable state framework for 2024.
I really like the patterns they've implemented though, looks a lot like the same framework I just built on top of MobX, websockets, and React for a recent project. They're headed in the right direction, but I'm not sure they realize how much more work they have to go before this is fully fleshed out.
Which brings in even more questions. What is the performance of these multiplayer experiences? Can I have 1000+ users all connected to the same chat session? What about 10,000?
(these numbers might seem high, but they're what I'm expected to deliver in my day-job)
What plans do you have for a third-party audit/review of your backend to verify the claims being made?
Its one thing to use this service on the basis of encryption claims - its another thing to have to clean up the mess from a forgotten API key being leaked somewhere... is there, therefore, a third party involved in an audit of Jazz?
Seems like you have lots of real world mobx experience.
Have you ever read this article, basically saying that every front end state (including mobx) basically ends up being a worse version of a standard database?
I ended up finding that article after running into lots of the challenges with mobx State tree. I ended up trying to use watermelondb, a sqlite wrapped for react native, but gave up entirely on offline due to bugs and project abandonment
Yes, I have read and found similar articles to what you've posted!
It is an ongoing exploration for us to find the best way to store/consume reactive state data within our client sites/apps. So far, MobX has given us a lot of leeway since we can create the data store we want for our data.
Going forward, I foresee us switching to something closer to WatermelonDB or maybe even just SQLite with a thin wrapper in React to create observability. I'm not 100% sure where it's going to go, but I agree with you that flexible state management for large platforms evolves fast and the difficulty of creating fast look-ups rapidly approaches "reinventing the DB" client-side.
I've had to build similar on top of SQLite for various other mobile/desktop apps, the problem hasn't really changed, the only difference is we're now using React + JS instead of C++, C#, or Java.
I would retort with, stop trying to chuck a SQL database everywhere.
The issue imho is that multiplayer synchronization (like Jazz) should rely on primitives(CRDT or similar) that you really can't hide under abstractions but should be part of the datamodel to allow for custom synchronization protocols for different parts of the datamodel or even exposing synchronization faults to the user.
An analogy would perhaps be how wrongly abstracted systems like CORBA and DCOM lost out (Even if you can run into them in crevices of enterprise systems) to things centered around HTTP calls or simpler message oriented systems like gRPC.
Plus the sync only works between clients AFAICT — literally all the listed backends are also “coming soon”. Which is troubling, I’d guess that almost all local-first applications need some sort of trusted verification server, at the very least. But maybe I’m biased/unimaginative; I suppose some kinds of collaboration apps (figma, google docs, etc) might work fine serverless? Certainly not games or AI agents, right?
This seems awesome, but my natural game-stopping questions are;
1. When will backends be supported?
2. Why doesn’t the site mention “local-first”?
Oh and just for fun;
3. Why “Collaborative Values” instead of what I learned in school, “Shared Memory”?
1. The sync is not just between clients, it by default works over a central backend infrastructure that syncs and persists. Plus you can create server workers (with jazz-nodejs) that also are clients to the same infrastructure and can do side-effects like API calls and interacting with “normal” databases in response to react state changing. And they can also mutate Jazz state.
2. The next version will. I like to think of Jazz as distributed state, of which local-first is a special case.
3. Shared memory to me sounds like concurrency is handled with locks, while Jazz uses CRDTs
Over the past few years, I've worked on and used a bunch of different frameworks to try to solve for distributed state. Jazz feels like it has the right "shape" - the right primitives to quickly build an app with magical powers like offline, real-time collab, etc.
If you can push the distributed state problem below the framework level, it becomes dead simple to build apps, which feels great.
Jess would know, DXOS is also amazing and in this space. I learned about DXOS at the local-first unconference after Strange Loop and was very impressed by Jess and his work.
anyone thinking about hanging their hat on writing decentralized, local first, crdt-driven software should also consider the complexity of changing your schema when there are potentially thousands of clients with different opinions of what that schema should be. some interesting research has been done[1] in this domain but i haven't seen any library of this ilk that supports real-world schema evolution in a way doesn't make me really, really wish i had a proper backend to lay down the law. the fact that migrations are in a "coming soon" state makes me wary of using jazz, and i wonder how they would approach this problem with the library as it is now.
It’s a tough problem! I think 90% of it is solved with GraphQL/ protobuf like rules (“only ever introduce new fields”)
There are some edge cases where you might loose easy access to some data if two clients migrate concurrently, but we’re hoping to provide patterns to mitigate these
Edit: Right now it all depends on you to implement migrations “the right way” but we hope to provide guardrails soon
I've been thinking about this as well and wondering if one possible approach to avoid the eventual messy database state—where fields are "append-only" and never deleted—might be to include the up/down migration logic as part of the payload.
This approach may require a central authority (with no access to user data) responsible solely for providing the schema and migration patterns as code transformations.
Since running arbitrary code from the payload introduces potential security risks, the migration code could be cryptographically signed, ensuring that only valid, trusted transformation code is executed.
A possible additional security layer would be to have the transformation code execute in a sandbox which can only output JSON data. (keeping a possible full before-migration version as backup in case something went wrong would always be a good idea)
Another option would be to use a transformation library for migrations, but in this case, the approach would only describe (as JSON) the functions and parameters needed to transition the schema from one version to another.
> I think 90% of it is solved with GraphQL/ protobuf like rules (“only ever introduce new fields”)
Agreed, that’s the only
sensible thing to do. Not sure it’s 90% though.
> but we’re hoping to provide patterns to mitigate these
Hope is not confidence inspiring for the most difficult problem at the heart of the system. That doesn’t mean it has to be impossible, but it needs to be taken seriously and not an afterthought.
Another thing you have to think about is what happens when data of a new schema is sent to a client on an older schema. Does the “merging” work with unknown fields? Does it ignore and drop them? Or do you enforce clients are up to date in some way so that you don’t have new-data-old-software?
Founder here - thanks for posting this! It’s getting late where I am so everyone who has questions please don’t be shy to ask, will elaborate in detail tomorrow!
How does the mesh (zero-server) work under-the-hood? What are some example of applications you see being possible with this library? Your site also mentions either using a central server or not having a server. The first idea that comes to mind (perhaps because of your chat example on the homepage) is a decentralised P2P messaging app - something like Messenger or WhatsApp but is completely free from central servers.
The underlying protocol is peer-to-peer sync, so the mesh is really just a bunch of geographically distributed servers that sync between each other as needed and act as "one giant syncing & persistence peer" for your app - mostly so you can sync stuff between devices even if they're not online at the same time, and to use it like cloud storage (I like to call it "S3 for collaborative data")
On a high level, it solves a similar problem: a full backend so you mostly only have to write a frontend.
But Jazz does so in a completely different (local-first) way: it implements shared state on top of CRDTs and implements user identity and permissions based on public-key cryptography. This means you can create, store and share data from the client (even while offline) while still benefitting from cloud storage and real-time sync between devices and users by default.
What happens to the mesh if this doesn't work out as a commercial enterprise and the company behind it goes away? Practically speaking how much of it is running on your computer's today?
Well the version of the Mesh that we offer would go away, but the framework is open source as is a simple but fully functional version of the sync server, so you could somewhat easily host your own mesh. Not having lock-in here is super important for us
Nice abstractions. Though I worry they’re going to be too rigid for some applications.
- how can I setup delivery receipts for messages in your chat app? I want to know if they got my message and when it was sent.
- how can I create a chat group where the entire list of access permissions is not transparently available to everyone? For example, customer support: I don’t want to give out a list of every employee because a customer opens a chat that any employee and respond to.
- how are you handling p2p sync to multiple devices with the same account? Are all of my devices made public to anyone I collaborate with? Or does one device always need to be online?
- add a “read” property to Message that the other person sets
- groups not only allow adding exact accounts, but also allow for “invites” which in your example only one employee could accept for a new support chat
- devices aren’t synced p2p by default but through the syncing server like everything else. Right now, all devices in one account use the same keypair for signing, so people you collaborate with can’t tell (except that they’re using different anonymous session ids)
I love building with Jazz. It's so refreshing to build apps without thinking about backends.
The number one thing I'm looking forward to is React Native support. Having local data that syncs is essential for many mobile apps, but there are no easy solutions yet. (Besides iCloud, which is limited to iOS/macOS)
With Jazz, I can see a future where building syncing, cross-platform apps becomes effortless.
Really interesting. Looking over their github, seems that at its core is a CRDT JSON structure with encryption and permissions built in. Storage, transport and auth are agnostic, but they offer some flavors (sqlite, websockets, clerk, react, nodejs). We're interested in svelte and rust support for now. Looks like the local-first space is gaining traction. Probably this is the most interesting execution so far.
We want to support as many environments as possible and are doing them in order of easiest & most requested - you are the first one to ask about Dart/Flutter
React Native is released (experimental)
After that will be really good support for Next.JS (Jazz for both SSR and client)
A bit later will probably be a Rust port, which then also makes bindings to Swift/Kotlin/Go/... easy
Readit News
- Cursors & carets
- Two way sync to your DB
- Video presence & calls
All of these are the key reasons I would be evaluating this framework to handle my data. All of these are not fully implemented yet.It is these key topics of live reloading/updating data that make or break an app. In my opinion, if you haven't concretely solved these problems, you haven't really built a viable state framework for 2024.
I really like the patterns they've implemented though, looks a lot like the same framework I just built on top of MobX, websockets, and React for a recent project. They're headed in the right direction, but I'm not sure they realize how much more work they have to go before this is fully fleshed out.
The coming-soon badges are about interop with traditional systems and higher level features we will add later.
The fundamentals are solved and you can build full multiplayer, local-first apps with it.
Does that make sense?
Which brings in even more questions. What is the performance of these multiplayer experiences? Can I have 1000+ users all connected to the same chat session? What about 10,000?
(these numbers might seem high, but they're what I'm expected to deliver in my day-job)
Its one thing to use this service on the basis of encryption claims - its another thing to have to clean up the mess from a forgotten API key being leaked somewhere... is there, therefore, a third party involved in an audit of Jazz?
Have you ever read this article, basically saying that every front end state (including mobx) basically ends up being a worse version of a standard database?
https://sqlsync.dev/posts/stop-building-databases/
I ended up finding that article after running into lots of the challenges with mobx State tree. I ended up trying to use watermelondb, a sqlite wrapped for react native, but gave up entirely on offline due to bugs and project abandonment
It is an ongoing exploration for us to find the best way to store/consume reactive state data within our client sites/apps. So far, MobX has given us a lot of leeway since we can create the data store we want for our data.
Going forward, I foresee us switching to something closer to WatermelonDB or maybe even just SQLite with a thin wrapper in React to create observability. I'm not 100% sure where it's going to go, but I agree with you that flexible state management for large platforms evolves fast and the difficulty of creating fast look-ups rapidly approaches "reinventing the DB" client-side.
I've had to build similar on top of SQLite for various other mobile/desktop apps, the problem hasn't really changed, the only difference is we're now using React + JS instead of C++, C#, or Java.
All roads so far have led to SQLite though.
The issue imho is that multiplayer synchronization (like Jazz) should rely on primitives(CRDT or similar) that you really can't hide under abstractions but should be part of the datamodel to allow for custom synchronization protocols for different parts of the datamodel or even exposing synchronization faults to the user.
An analogy would perhaps be how wrongly abstracted systems like CORBA and DCOM lost out (Even if you can run into them in crevices of enterprise systems) to things centered around HTTP calls or simpler message oriented systems like gRPC.
This seems awesome, but my natural game-stopping questions are;
1. When will backends be supported?
2. Why doesn’t the site mention “local-first”?
Oh and just for fun;
3. Why “Collaborative Values” instead of what I learned in school, “Shared Memory”?
2. The next version will. I like to think of Jazz as distributed state, of which local-first is a special case.
3. Shared memory to me sounds like concurrency is handled with locks, while Jazz uses CRDTs
If you can push the distributed state problem below the framework level, it becomes dead simple to build apps, which feels great.
[1] https://www.inkandswitch.com/cambria/
There are some edge cases where you might loose easy access to some data if two clients migrate concurrently, but we’re hoping to provide patterns to mitigate these
Edit: Right now it all depends on you to implement migrations “the right way” but we hope to provide guardrails soon
This approach may require a central authority (with no access to user data) responsible solely for providing the schema and migration patterns as code transformations.
Since running arbitrary code from the payload introduces potential security risks, the migration code could be cryptographically signed, ensuring that only valid, trusted transformation code is executed. A possible additional security layer would be to have the transformation code execute in a sandbox which can only output JSON data. (keeping a possible full before-migration version as backup in case something went wrong would always be a good idea)
Another option would be to use a transformation library for migrations, but in this case, the approach would only describe (as JSON) the functions and parameters needed to transition the schema from one version to another.
Agreed, that’s the only sensible thing to do. Not sure it’s 90% though.
> but we’re hoping to provide patterns to mitigate these
Hope is not confidence inspiring for the most difficult problem at the heart of the system. That doesn’t mean it has to be impossible, but it needs to be taken seriously and not an afterthought.
Another thing you have to think about is what happens when data of a new schema is sent to a client on an older schema. Does the “merging” work with unknown fields? Does it ignore and drop them? Or do you enforce clients are up to date in some way so that you don’t have new-data-old-software?
But that's not exactly convenient for the users.
But Jazz does so in a completely different (local-first) way: it implements shared state on top of CRDTs and implements user identity and permissions based on public-key cryptography. This means you can create, store and share data from the client (even while offline) while still benefitting from cloud storage and real-time sync between devices and users by default.
- how can I setup delivery receipts for messages in your chat app? I want to know if they got my message and when it was sent.
- how can I create a chat group where the entire list of access permissions is not transparently available to everyone? For example, customer support: I don’t want to give out a list of every employee because a customer opens a chat that any employee and respond to.
- how are you handling p2p sync to multiple devices with the same account? Are all of my devices made public to anyone I collaborate with? Or does one device always need to be online?
- groups not only allow adding exact accounts, but also allow for “invites” which in your example only one employee could accept for a new support chat
- devices aren’t synced p2p by default but through the syncing server like everything else. Right now, all devices in one account use the same keypair for signing, so people you collaborate with can’t tell (except that they’re using different anonymous session ids)
The number one thing I'm looking forward to is React Native support. Having local data that syncs is essential for many mobile apps, but there are no easy solutions yet. (Besides iCloud, which is limited to iOS/macOS)
With Jazz, I can see a future where building syncing, cross-platform apps becomes effortless.
I recently hired someone who is a big svelte fan so we’ll have bindings for that soon. Rust is coming a bit later.
Are there plans for supporting dart/Flutter as well in the future?
React Native is released (experimental)
After that will be really good support for Next.JS (Jazz for both SSR and client)
A bit later will probably be a Rust port, which then also makes bindings to Swift/Kotlin/Go/... easy