Live data from Hacker News

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

tinybase.org

51–60 of 65 posts

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

#51

Pretty cool. I do a lot of game dev and have searching for solutions like CastleDB but built in the NodeJS ecosystem. This looks like it could check a lot of boxes for me. What I want is to be able to define my tables with something like JSON schema, and automatically have the typescript typings available when querying. The data would be serialised to Git friendly json, and there would also be support for different m…

Yes, one imminent idea I have is to codegen a .d.ts from an explicit schema (or even implied, from populated data). One might even be able to produce typed functions like `setPetsPrice(petId, price: number)` instead of `setCell('pets', petId, 'price', value: any)`.

Sort of an ORM trope, but hey, why not!

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

#52

Excuse my lazy reading of the site but - is this web based, built on top of IndexedDB?

No, there are no dependencies. It has its own in-memory data structure, and ways to serialize it to other, more persistent, formats. I could imagine an option for more fully fledged RDBMSs being those persistence layers though.

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

#53
post #33

Earlier quoted context omitted.

Ouch, tough crowd, but fair enough! I wonder if I should have a font-weight (or -family) toggle alongside the dark mode setting. Would be a shame for people to miss out on reading about the software because of the typography!

> Ouch, tough crowd Meta: hacker news is known for this, but it's really not personal (modulo very few mean folks). People have an adversarial mindset and will poke holes in everything, even things that are awesome. If the biggest critique against your project is the font (superficial) you can interpret is as an absence of more fundamental criticism. Fonts and fancy looking things in particular tend to be critizised…

Yep, I guess I should be thankful if that's the main complaint! And thanks for the spec for the 'basic typography' toggle option :)

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

#54
post #37

A comparison to PouchDB would make a great reference point to help people understand the use case. From what I can see in 2 mins of reading it looks like it's more relational which should be a plus, but then on the downside there's much less of a story on the sync side, with remote persistence ending at offering you interfaces to persist your data but not an actual data store that works. By comparison, PouchDB connec…

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!!!

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

#55
This looks really cool, love seeing more innovation in this space!

At first glance this seems to be mostly targeted towards single-user apps where each user would have their own database that can be sync'ed to a remote server, but still isolated from data for other users, similar to the CouchDB+PouchDB model?

At least it looks that way since I couldn't see anything around authorization and conflict resolution. Not that there's anything wrong with focusing on this use case, a lot of apps can function perfectly fine this way.

A few other interesting new players that use an optimistic local update + server validated mutation model to support collaboration:

https://replicache.dev/

https://clientdb.dev/

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

#56
I’m developing a local-first app and a game with Electron and I am using my own “data store” by simply storing serialized JavaScript object literals in localStorage. It works, but at times it’s a bit annoying and tedious to use, so I’ll definitely check this out.

My only other frame of reference for something similar is TaffyDB, though It would not call it “reactive”.

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

#57
Respect to the authors of course, however I am not sure if it helps solving common data sync problems to introduce one more datastore with it´s own special query language. Maybe I am misunderstanding the use case.

I like https://orbitjs.com/ very much - it puts the focus on the right area.

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

#58
post #35

I've been looking for something like this but sadly I can't use it because I can't rely on JS. I wish there was some decent local-first event based db that was language agnostic. Very few projects are reactive/streaming. If anyone's interested my current workaround is piping JSONL between my processes (and into files) and it works pretty well, but lacks more advanced features.

Realm is an reactive local database that is largely language agnostic.

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

#59

This looks really cool, love seeing more innovation in this space! At first glance this seems to be mostly targeted towards single-user apps where each user would have their own database that can be sync'ed to a remote server, but still isolated from data for other users, similar to the CouchDB+PouchDB model? At least it looks that way since I couldn't see anything around authorization and conflict resolution. Not th…

Is there an open-source alternative to replicache yet?

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

#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 too much domain knowledge (which we have but don't want to think about when doing things we think should just automatically work, like synching; like replicache which is just too much work for us on our existing datasets) or are very hacky, as in, lose data and require you to write code to fix that.
Post reply on HN