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

TinyBase v2.0: reactive data store for local-first apps

tinybase.org

Post reply on HN
Print view View original

61–65 of 65 posts

Re: TinyBase v2.0: reactive data store for local-first apps

#61

Post by mfbx9da4 »

jamesgpearce wrote: post #29
mfbx9da4 wrote: post #26

Earlier quoted context omitted.

Yeah but I feel like it could be used for that, if only retrieval and storage could be done incrementally…

Correct. I think this could be done, but I would need to think a little about how best to. Thank you for the idea!

This is how I see it could work:

* Queries are encoded into sql and matcher functions

* Whenever data is mutated a change set is emitted - eg similar to immer

* This change set is used to generate SQL UPDATE statements

* The change set is also sent to matcher functions, the matcher functions update the query results accordingly

Re: TinyBase v2.0: reactive data store for local-first apps

#62

Post by thomasfedb »

tluyben2 wrote: post #60

Ah, I was whining in the surrealdb thread for new advances in this space over couch/pouch (which we have been using for over a decade). Would be great to see comparisons, especially in areas where couch/pouch are bad and new solutions are better. We have not moved anywhere yet because couch/pouch, when you are used to it development wise, is automatic. You do nothing and it works. Other solutions we tried require way…

Interesting to hear that Couch/Pouch “just work”. I’ve been looking at using them and I find there’s a lot to wrap your head around. In particular for apps where different users should see different sets of shared records.

Re: TinyBase v2.0: reactive data store for local-first apps

#63

Post by tluyben2 »

thomasfedb wrote: post #62
tluyben2 wrote: post #60

Ah, I was whining in the surrealdb thread for new advances in this space over couch/pouch (which we have been using for over a decade). Would be great to see comparisons, especially in areas where couch/pouch are bad and new solutions are better. We have not moved anywhere yet because couch/pouch, when you are used to it development wise, is automatic. You do nothing and it works. Other solutions we tried require way…

Interesting to hear that Couch/Pouch “just work”. I’ve been looking at using them and I find there’s a lot to wrap your head around. In particular for apps where different users should see different sets of shared records.

Yes, that’s correct, but we have been used to thinking that way for a decade. I don’t remember how painful it was in the first place, but once you think in that way, things fall in place.

Re: TinyBase v2.0: reactive data store for local-first apps

#64

Post by thomasfedb »

tluyben2 wrote: post #63
thomasfedb wrote: post #62

Earlier quoted context omitted.

Interesting to hear that Couch/Pouch “just work”. I’ve been looking at using them and I find there’s a lot to wrap your head around. In particular for apps where different users should see different sets of shared records.

Yes, that’s correct, but we have been used to thinking that way for a decade. I don’t remember how painful it was in the first place, but once you think in that way, things fall in place.

Any good resources you can recommend that would show me “the beaten path” for e.g. a todo list where users can selectively share items, or join teams - just a step or two more than the usual “every user gets their own data only”.

Re: TinyBase v2.0: reactive data store for local-first apps

#65

Post by jamesgpearce »

zmmmmm wrote: post #54
jamesgpearce wrote: post #49

Earlier quoted context omitted.

Is it bad to admit... I don't really know... much about PouchDB? But you've sold me on the concept. I have plenty of prior art to read up on, it seems!

I actually love it when people invent things without full knowledge of prior art - a lot of innovation happens only when people aren't biased by what is already there. Perhaps if you knew all about PouchDB you might not have had enough motivation to do this, and then this gap of a relational reactive store would not have been explored. What you have done looks really great!!!

Thanks but I do feel a bit guilty :)
Post reply on HN