Can you point me to what gave you this impression? We implement our own query engine for Triplit and use a fork of tuple-database[1] for storage which is low level database that can store to SQLite (we do on the server) but in the browser it uses either an in-memory btree or IndexedDB.
Regarding compatibility with our databases, we do have some internal experiments of running a Triplit Server in front of existing databases as almost like a syncing cache. Still very experimental but maybe you'd be more into that use case.
Very cool to see a use of tuple-database in the wild! I've known about that project for a while and thought it looked really cool, but I don't have a use for it.
I agree with you w/r/t "Why build your own query builder" though since (AFAIK) you can't touch the underlying SQL. I'm making heavy usage of FTS5 in my app, and it doesn't look like they support that.
And, to be fair, feathers/rethink also have the weaknesses you list:
- Why build your own query builder
- This also isn't really something you could drop into an existing project very easily
React Query (and other query caching libraries) are great until you have overlapping data between your queries. E.g. you edit a message in one place but other queries that show that same message (like a preview in your chat list) don't update.
Having a complete query engine on the client makes this a lot easier to deal with. It's why most popular messaging apps will use SQLite on the client to render the UI and build their own sync engine to keep it up to date with the backend.
