Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Jazz – Apps with Distributed State

jazz.tools

Post reply on HN
Print view View original

61–70 of 179 posts

Re: Jazz – Apps with Distributed State

#61

Post by KPGv2 »

aboodman wrote: post #47
theanzelm wrote: post #22

Earlier quoted context omitted.

It is already persisting and syncing data (fully encrypted) between the cloud and other users. You can think of Jazz as a distributed database itself. 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?

Does it store data persistently anywhere (on servers?). If so where?

It looks like it stores it on Jazz Flex, a paid service.

Free tier is 1GB of storage, and it goes up from there.

Re: Jazz – Apps with Distributed State

#62

Post by softfalcon »

theanzelm wrote: post #22
softfalcon wrote: post #19

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…

It is already persisting and syncing data (fully encrypted) between the cloud and other users. You can think of Jazz as a distributed database itself. 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?

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)

Re: Jazz – Apps with Distributed State

#63

Post by softfalcon »

jimmywetnips wrote: post #37
softfalcon wrote: post #19

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…

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? 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…

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.

All roads so far have led to SQLite though.

Re: Jazz – Apps with Distributed State

#64

Post by rattray »

gocken wrote: post #41
yawnxyz wrote: post #6

Earlier quoted context omitted.

very cool! I was there for maybe 2 minutes before HN took the system down :D

Not very cool if it breaks under hardly any load. You'd think they'd test their tech demos on more than a handful of people before launching. This doesn't give much confidence at all in their product.

note the creator did not intend for the project to be posted to hn at this time

Re: Jazz – Apps with Distributed State

#65

Post by salomonk_mur »

theanzelm wrote: post #34
graypegg wrote: post #31

Edit: This IS being used to build a product, see reply below One thing I always find weird about these sorts of projects is I get the feeling this is a framework built up from scratch. I've always had really bad luck doing that. Extracting and refining something from a running application always feels like you catch the cases that actually matter. It's neat that it's quick to start, but I think that's mostly because…

Jazz is built specifically for a work-in-progress, but full app (essentially a Notion clone, TBA) and all the design choices are driven by that. Completely agree that this is the only way to create frameworks. Edit: also other people are building full apps with it too which I’ll showcase soon. https://learn-anything.xyz/ is one example, https://invoiceradar.com/ is another.

That first link is great. Thank you so much for sharing it.

Re: Jazz – Apps with Distributed State

#67

Post by svilen_dobrev »

softfalcon wrote: post #63
jimmywetnips wrote: post #37

Earlier quoted context omitted.

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? 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…

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 t…

i have built similar thing long time ago, using couchdb as replication-storage mechanism, and it's variants on non-server platforms - touchdb/android/ios pouchdb/js-browser etc , but yes, except serverside, all other platforms still had sqlite underneath.

Long live sqlite :)

Re: Jazz – Apps with Distributed State

#68

Post by bhl »

softfalcon wrote: post #63
jimmywetnips wrote: post #37

Earlier quoted context omitted.

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? 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…

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 t…

I've done the same with mobx-state-tree, and realized I was essentially building a relational database with cache-ing in JavaScript.

The only thing SQLite is missed, which is important when integrating with React, is incremental view maintenance: how do we maintain as much immutable state on an update as possible to avoid wasteful re-renders?

Post reply on HN