matlin

More niche use case but this would be awesome for communicating between contexts in web app (e.g. web worker, iframe, etc)

With React Native yes but not yet with Swift. There's been quite a few requests to my surprise through--I figured CloudKit, etc would be sufficient on iOS but I don't have experience there.

Great catch, fixed!

PouchDB and CouchDB were what inspired me to build Triplit[1]. The idea of having an identical (or merely similar in the case of Pouch/Couch) query engine accessible on client and server is insanely powerful.

The author links to a much longer post on handling conflicts which is worthy of its length because it's not a pleasant experience with this setup.

I highly recommend trying a modern setup from one of the many new local first solutions [2]

1. https://triplit.dev

2. https://www.localfirst.fm/landscape

My ideal version of this is simple: just define the queries you want (no matter how complex) and the you'll get exactly the data you need to fulfill those queries, no more, no less. And the cherry on top would be to have your queries update automatically with changes both locally and remote in close to real-time.

That's basically what we're doing with Triplit (https://triplit.dev), be it, not with SQL--which is a plus for most developers.

You should check out Triplit as well, we have React Native support[0] and the best Typescript integration by far

0. https://www.triplit.dev/docs/frameworks/react-native

We apply incremental, streamable "joins" (relational queries) for real-time syncing between application client and server. I think much of the initial research in this space was around data pipelines but the killer app (no pun intended) is actually in app development

I've used React Native quite a bit in the past and I gotta say I wish it didn't have to exist at all.

It's often times fine on iOS and then incredibly slow on Android. Hermes is very exciting but still requires many polyfills to make simple NPM packages work. I hope one day, the web (and embedding web apps on mobile) makes React Native fully obsolete.

I've made just this!

Docs for it: https://www.triplit.dev/docs/frameworks/tanstack-router#exam...

It by default uses IndexedDB but can also use SQLite but does real time, relational querying and (optionally) syncs with you server.

Re: developer ergonomics, this is our primary focus so I don't love to get your feedback on!

A lot of the newer local first systems, like Triplit (biased because I work on it), support partial replication so only the requested/queried data is sent and subscribed to on the client.

The other issue of relying on a just the server to build these highly collaborative apps is you can't wait for a roundtrip to the server for each interaction if you want it to feel fast. Sure you can for those rare cases where your user is on a stable Wifi network, on a fast connection, and near their data; however, a lot computing is now on mobile where pings are much much higher than 10ms and on top of that when you have two people collaborating from different regions, someone will be too far away to rely on round trips.

Ultimately, you're going to need a client caching component (at least optimistic mutations) so you can either lean into that or try to create a complicated mess where all of your logic needs to be duplicated in the frontend and backend (potentially in different programming languages!).

The best approach IMO (again biased to what Triplit does) is to have the same query engine on both client and server so the exact query you use to get data from your central server can also be used to resolve from the clients cache.

You'd probably enjoy Triplit then--especially if you're using Typescript.

https://triplit.dev

Seph (author) also has a reference implementation in Typescript: https://github.com/josephg/eg-walker-reference

I've stated before that I think the main thing holding back collaborative text / sequence CRDTs is integration with a production database.

Eg-walker looks interesting because it might lend itself to be integrated into a database because the operations are immutable and only appended. However, to demonstrate the effectiveness of these algorithms library authors (see Yjs, DiamondTypes, etc) build stand-alone data structures (usually specialized search trees) that most databases already provide.

Personally, I've been trying to adapt a Piece Table[1] to be collaborative and stored in Triplit[2] which runs on both client and server and already implements logical clocks but I might see how well I can adapt this algorithm instead!

1. https://en.wikipedia.org/wiki/Piece_table 2. https://github.com/aspen-cloud/triplit

Do you see Ladybird beating the incumbent browsers in any dimension .e.g. performance, usability?, security, etc?

Personally, I much prefer developing for the web than native so if there were APIs exclusive to Ladybird it might create a nice virtuous cycle of developers targeting Ladybird to do new things and users using Ladybird to try those new experiences.

Glad you've enjoyed using Triplit!

on self-hosting: We're cleaning up the docs on self-hosting to make the configuration clearer, thanks for point that out.

on querying: Yeah we don't have aggregations yet but it's on our roadmap. Don't want to over promise but I think we can make something awesome here by leverage our incremental querying engine. Like consider a data dashboard that needs to be updated every hour; in a traditional system (postgres, mongo, etc) you would need to rerun the query from scratch each time. Our plan is to create something closer to what Materialize does and just process the new data so it's much more efficient and can just update continuously rather than every hour.

re Evolu: I haven't actually gotten a change to try it out but there might be in someone in our Discord[1] that has that could compare/contrast

1. https://triplit.dev/discord

Can you point to which part in the license gives you the impression that using an unmodified version of AGPL code requires using AGPL for your entire application?

Either way your interpretation is not our intention so I'll make sure that's clarified.

This is a great question! The short answer is by maintaining backwards compatibility in your schema--it's basically the easiest way to guarantee compatibility. We have warnings in place to let you know when you've made a change that isn't backwards compatible, you can read about it in our docs: https://www.triplit.dev/docs/schemas/updating#pushing-the-sc...

However, overtime this can naturally lead to a mess of a schema definition that has a lot of confusing names. We haven't released a solution to fix this yet but we're working on a few things that should make this less painful. For background on the various approaches, the Cambria doc is an amazing resource: https://www.inkandswitch.com/cambria/

It's not currently possible to use MongoDB with Triplit, you would use Triplit's server instead but it's very easy to setup with React: https://www.triplit.dev/docs/quick-start

Got it, that makes sense. Probably could spin up Node process but of course that requires having Node installed or bundled with the app.

Yeah it's totally usable as is but we're nearly finished with a new system that has more granular controls like delete, preUpdate, postUpdate, insert, and read. We'll still support the existing rules for backwards compatibility.

I thought Tauri was just using native web renderers? Seemingly Triplit should work out of the box.

No real reason other than we wanted to customize it and move quickly. I'm sure Chet, the maintainer, wouldn't oppose any of the changes we've made.

Triplit uses its own standalone server (similar to other database servers) which you can talk to via HTTP https://www.triplit.dev/docs/http-api

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.

Thanks for the kind words and help identifying issues in Triplit as you've built your app!

There are adapters for LevelDB, LMDB, and File storage. We just use SQLite out of the box because it's fast and reliable. We'll make those other adapters more accessible in the future.

That's cool that you saw my presentation!

Re: Flutter (and other native support) it's something we've thought a lot about (Flutter specifically comes up often) but we decided to focus on pure-Typescript to start because it's a big enough market (I'm personally a big believer in the future of PWA's) and we know we can make the best experience by focusing on it. I do think that we'll eventually make something more platform agnostic but not sure when that will happen.

Re: ElectricSQL & Supabase: both teams are obviously very talented and thoughtful and, I believe, will continue growing in the SQL space which is the most fundamental difference between our approaches. I think Triplit can make the best experience for developers by avoiding SQL and think there's undoubtedly room for both philosophies.

Right, that's a good clarification.

Not currently but we have an internal tool that does bi-directional syncing using Postgres's replication protocol and WAL2JSON. It's not quite ready for prime time but we're hoping to get it into people's hands soon.

It's been great working with you to get things right. Your feedback and bug reports have helped immensely to shape Triplit!

From my understanding, if someone were to create a private fork of Triplit Server add some modifications and then launch a hosted service (i.e. serving the modified Triplit Server over the internet) they wouldn't be compelled to open-source their modifications under GPL but would under AGPL.