Excuse my lazy reading of the site but - is this web based, built on top of IndexedDB?
TinyBase v2.0: reactive data store for local-first apps
41–50 of 65 posts
Re: TinyBase v2.0: reactive data store for local-first apps
#42For the uneducated like me: what is a "reactive data store"?
Re: TinyBase v2.0: reactive data store for local-first apps
#43I'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.
https://pocketbase.io/ may be of interest to you
Re: TinyBase v2.0: reactive data store for local-first apps
#44For the uneducated like me: what is a "reactive data store"?
A store where you do a query, get a result set, but also a callback (reactivity) in the future if that query would return a different result set if you were to run it again.
Imagine a "row count" HTML element which is automatically updated (reactive) when a different part of the web app inserts a row in the data store.
Re: TinyBase v2.0: reactive data store for local-first apps
#45I'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.
I've been working on something that may fit your criteria. The API is kafka-like and it's whole goal is to provide an easy to use local-first stream datastore/data-engine.
It currently only has support for Rust and Python clients but working on expanding to node(JS) and C/C++ in the future.
Re: TinyBase v2.0: reactive data store for local-first apps
#46Author here, if anyone has any thoughts or feedback. Bring it on!
Did you use this package in your projects?
Re: TinyBase v2.0: reactive data store for local-first apps
#47Pretty 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…
RxDB with PouchDB has support for typescript, json schema, and binary attachments. Moving the attachments to the file system will be up to you.
Re: TinyBase v2.0: reactive data store for local-first apps
#48A 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…
You can also use PouchDB with RxDB, which _is_ reactive.
Re: TinyBase v2.0: reactive data store for local-first apps
#49A 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!
Re: TinyBase v2.0: reactive data store for local-first apps
#50For the uneducated like me: what is a "reactive data store"?
By "reactive" I mean... if the data changes, the UI does (or at least, an event is fired, and then you can drive a React render, for example, from that). In contrast, you expect to have to poll an RDBMS for updates. An MIT team recently wrote an awesome essay on the same concept (https://riffle.systems/essays/prelude/), wrapping SQLite for the purpose.
With "data store", rather than "database", I'll admit I am hedging my bets. Through one lens, this library can look more like an app-level store in a classic React sort of way. Through another (most notably the table/row/cell structure), it looks like an RDBMS. I'm not ready to go all-in and declare it's a database yet. Such nomenclature comes with Assumptions™.