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.
Jazz – Apps with Distributed State
151–160 of 179 posts
Re: Jazz – Apps with Distributed State
#152Seems very promising! Couple of qs:
1) How high is the pubkey overhead / isn’t this a lot of cryptography?
2) How do migrations work?
Re: Jazz – Apps with Distributed State
#153Reminds me of https://github.com/amark/gun
Re: Jazz – Apps with Distributed State
#154I guess it would be nice to see a comparison with other CRDTs (Automerge, Yjs, Loro) and syncing frameworks/databases (PowerSync, RxDB, SignalDB, InstantDB).
Re: Jazz – Apps with Distributed State
#155anyone 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…
Couldn't you just use api/schema versioning?
Re: Jazz – Apps with Distributed State
#156anyone 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…
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.
Re: Jazz – Apps with Distributed State
#157anyone 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
Re: Jazz – Apps with Distributed State
#158I 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
Re: Jazz – Apps with Distributed State
#159Earlier quoted context omitted.
Just wanted to apologise to everyone for this, this kind of stuff drives me nuts and I'm not sure how I never noticed - it seems to be a result of how we use the iframe to render the chat example. Investigating!
Update: this should be fixed now
Thanks for the quick response!
Re: Jazz – Apps with Distributed State
#160anyone 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 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?