Reminds me of https://github.com/amark/gun
If both projects merge they can call it Spirit Finger Guns
Jazz – Apps with Distributed State
161–170 of 179 posts
Re: Jazz – Apps with Distributed State
#162I guess it would be nice to see a comparison with other CRDTs (Automerge, Yjs, Loro) and syncing frameworks/databases (PowerSync, RxDB, SignalDB, InstantDB).
There might be a vendor neutral comparison page between technologies soon that we’ll be part of
Kudos on the vendor-neutral ! Too many vendors doing their own "comparisons" which only list the features their tech excels in.
Re: Jazz – Apps with Distributed State
#163Earlier quoted context omitted.
Couldn't you just use api/schema versioning?
You could of course effectively create a new database whenever you make a new schema. But that's not exactly convenient for the users.
I think he meant up/down data transformation migrations, not entire new dbs or collections.
Re: Jazz – Apps with Distributed State
#164Earlier quoted context omitted.
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 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 afterthough…
You’re right, I was just being short. Will give you a longer and more concrete answer tomorrow
Re: Jazz – Apps with Distributed State
#165What about Golang support?
Re: Jazz – Apps with Distributed State
#166anyone 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…
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.
Re: Jazz – Apps with Distributed State
#167Kudos to your work - I have been following the project for a while and it's impressive what you have build mostly by yourself and without any of the usual VC funding!
Re: Jazz – Apps with Distributed State
#168Kudos to your work - I have been following the project for a while and it's impressive what you have build mostly by yourself and without any of the usual VC funding!
Thank you! Disclaimer: as of recently I have funding but the approach will stay the same!
Re: Jazz – Apps with Distributed State
#169Earlier quoted context omitted.
That sounds a lot more promising! 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)
Eventually, yes! The origin story of Jazz is that I did a lot of experiments and research to convince myself of satisfying performance characteristics. Right now, the pure-TypeScript implementation is not very optimised and I'm very intentionally optimising it as needed for early adopter apps instead of predicting where bottlenecks are. So if you start building a chat app with 10s of thousands of users interacting, w…
this is amazing, keep up the great work. been wanting something like this forever
Re: Jazz – Apps with Distributed State
#170Earlier quoted context omitted.
Also Instant is a database (it has queries and so forth, more appropriate for bigger data). I would put Jazz at the document sync side of the spectrum: https://x.com/aboodman/status/1843042582672355834
This is fair, thanks for chipping in, Aaron! With decentralised I always like to be very precise: - Jazz is decentralised in a "source of truth" sense. You mutate data locally and sync edits between participants until you reach eventually consistent history (and thus state, as per the underlying CRDTs) - the protocol is peer-to-peer - the way you use it typically is in a very centralised way. You use a central sync a…
Makes sense. This is a smart tradeoff.