by matlin on 6/25/24, 1:53 PM with 100 comments
(npm|bun|yarn) create triplit-app
We finally decided to build the system we always wanted. Triplit enables your app to work offline and sync in real-time over websockets with an enjoyable developer experience.
Triplit lets you (1) define your schema in Typescript and simply push to the server without writing migration files; (2) write queries that automatically update in real-time to both remote changes from the server and optimistic local mutations on the client—with complete Typescript types; (3) run the whole stack locally without having to run a bunch of Docker containers.
One interesting challenge of building a system like this is enabling partial replication and incremental query evaluation. In order to make loading times as fast as possible, Triplit will only fetch the minimal required data from the server to fulfill a specific query and then send granular updates to that client. This differs from other systems which either sync all of a user’s data (too slow for web apps) or repeatedly fetch the query to simulate a subscription (which bogs down your database and network bandwidth).
If you’re familiar with the complexity of cache-invalidation and syncing, you’ll know that Triplit is operating firmly in the distributed systems space. We did a lot of research and settled on a local first approach that uses a fairly simple CRDT (conflict-free replicated data type) that allows each client to work offline and guarantees that they will converge to a consistent state when syncing. It works by treating each attribute of an entity as a last writer wins register. Compared to more complex strategies, this approach ends up being faster and doesn’t require additional logic to handle conflicting edits between concurrent writers. It’s similar to the strategy Figma uses for their collaborative editor.
You can add Triplit to an existing project by installing the client NPM package. You may self-host the Triplit Server or pay us to manage an instance for you. One cool part is that whether you choose to self-host or deploy on Triplit Cloud, you can still use our Dashboard to configure your database or interactively manage your data in the Triplit Console, a spreadsheet-like GUI.
In the future, we plan to add APIs for authentication, file uploads, and presence to create a Supabase/Firebase-like experience.
You can get started by going to https://triplit.dev or find us on Github https://github.com/aspen-cloud/triplit. Thanks for checking us out and we are looking forward to your feedback in the comments!
by thanhnguyen2187 on 6/26/24, 3:01 AM
Congrats on the launch and thanks for the awesome product! I've been using Triplit in one of my projects [1], and it do work as expected. In my self-promotion on Reddit [2], I posted about Triplit as well:
> I think Triplit is a nice database and works as expected. It's data model fits well with what I have in mind (more decentralized/P2P instead of having a single centralized database as the source of truth), but there are 2 areas I find lacking:
> - Server side/self-hosted: Triplit server requires a token for authentication. Triplit's documentation has a section about how to start the server without explicitly showing how to generate the token, which is mildly inconvenient. Therefore, on self-hosting the server, I opted for using their CLI command dev since the command has the token generation that I needed. I know it is not a good security practice as when the command is used as a system service, the token will be logged in plain text, but I have a bigger problem when someone can access that anyway.
> - Query language: I find their custom query DSL not as expressive as a full-fledged query language (lacking UNIQUE and COUNT like SQL is on the top of my mind). You'll have to do a bit of data aggregating yourself.
Recently, I found Evolu [3], which is quite similar to your project in terms of scope and functionalities as well. From a quick skim of their documentation, I think the differences are:
- Triplit have `.subscribe()`, while Evolu don't
- Evolu's querying is more familiar/advanced (typed SQL via Kysely)
- In the browser, Evolu seems to use SQLite on top of OPFS, while Triplit uses IndexedDB
I think there are more intricacies on the way Triplit differs from Evolu, so can you enlighten me on that?
Really appreciate your comment! Thanks!
- [1]: https://github.com/thanhnguyen2187/cryptaa
- [2]: https://www.reddit.com/r/sveltejs/comments/1dndpj8/cryptaa_a...
- [3]: https://www.evolu.dev/docs
by lars512 on 6/26/24, 5:03 AM
My context here is having worked in the past on a mobile health app, and recalling all the pain we had around this problem.
by Kiro on 6/26/24, 8:29 AM
I have the same questions about Supabase and Firestore so it seems like I'm missing something.
by armincerf on 6/25/24, 6:27 PM
Overall triplit has been really great, both as a frontend dx and also their support - whenever we find an issue or have a feature it gets handled very quickly by the team which is awesome!
As soon as they have an answer for HA deployments we will be moving more critical data there instead of Postgres
by candiddevmike on 6/25/24, 5:55 PM
by satvikpendem on 6/25/24, 6:28 PM
So with all that, my question is, is there a reason you guys went with more of a full language level solution rather than being more agnostic to the client and server? It seems harder to support other languages and frameworks other than JS based ones in the future, but I suppose the market for that is already big enough. ElectricSQL etc also have SDKs for TypeScript as well as Flutter and others so they are similar to your solution but it seems like they can support more clients and servers in the future just by building SDKs for them.
Another question, looks like you eventually want to compete with Supabase but they are already experimenting with database level syncing and CRDTs in Postgres [2] and might catch up with your solution, any thoughts on that?
[0] https://www.youtube.com/playlist?list=PLTbD2QA-VMnXFsLbuPGz1...
by curtisblaine on 6/25/24, 5:41 PM
by munzman on 6/25/24, 10:01 PM
by tanishqkanc on 6/25/24, 7:22 PM
- Good sane query language (not SQL) - Great typescript support - Offline support - React native support
The cherries on top is that it's open source and self-hostable.
by sagarjs on 6/25/24, 6:31 PM
by arcticfox on 6/25/24, 4:39 PM
But also I’m getting old, and I had the same feeling when RethinkDB came out. Do you guys have any thoughts on how your system compares to what they were doing and what eventually happened to them?
by kouohhashi on 6/26/24, 12:20 AM
by alex_lav on 6/25/24, 7:19 PM
I'm looking through the docs for more info on this line:
> The server supports different storage adapters, such as SQLite
What are the other storage adapters? I may just be blind, so if so please forgive me!
by syedmsawaid on 6/25/24, 8:24 PM
by stevage on 6/25/24, 11:12 PM
by 8mobile on 6/26/24, 4:55 AM
by terpimost on 6/25/24, 4:55 PM
by mrtesthah on 6/25/24, 6:12 PM
by pantulis on 6/26/24, 2:06 PM
by Jayakumark on 6/25/24, 4:38 PM
by v4akukdX on 6/26/24, 6:09 PM
by danman114 on 6/26/24, 12:02 PM
I'd like to mention the Meteor.js framework (https://www.meteor.com/) too, which is in a bit of a transitioning phase right now to Meteor version 3, but is a really amazing full-stack app building solution I and many others have been working with for ~10 years.
It has a lot of batteries included, build system, pluggable frontend frameworks, lots of libraries, based on node.js, meaning it's pretty much compatible with the Node.js environment.
It's based on a really pretty simple syncing strategy for years:
It's original client side data provisioning layer is based on having
a) MongoDB on the Server and b) a javascript-native implementation of a subset of MongoDB in the Client.
Using a publish / subscribe mechanism the client can subscribe to the subset of data relevant to his current view, eg. dependent on the current user & view.
Updating is theoretically possible by using a syncing mechanism via writes into the client database and an elaborate allow/deny mechanism, but in practice most people use the following simple workflow:
Meteor also provides a method-call-mechanism by which a client can call the server to do (or fetch) stuff. So that's basically RPC in a very simple but powerful format.
These methods also allow for "client side simulations", optimistic updates to the client side database, with the changes getting rolled back / updated once the server part of the method has done it's updating of the database.
So the workflow for working & updating data in the DB looks like this:
- Data is "canonical" on the server DB
- Client subscribes for the necessary data for its client side cache
- When the user triggers an action, the client calls a method on the server, eg: "likePost(post_id)"
- The client side simulation can actually increase the like count on the "Post" document in the local minimongo database
- The server then executes the method & increments the like count in its database, if the request is valid
- The client updates its UI always reactively as soon as the data in its local db has changed.
All of this is very performant as long as you keep it cool and subscribe only what's actually needed for the current view,
Oh, and all of this has fine grained reactivity, on the client. The whole solution is really powerful, while deceptively simple.
Having the same API on both client and server allows for "isometric" code, meaning code which runs on both the client and the server, so you don't have to have two different versions of helper code, which is really cool too.
Meteor.js is pretty much a bit like "the old PHP experience" to me: As a full Stack developer I can write powerful apps with only one codebase which is shared in parts between client and server.
Link to Pub/Sub docs: https://docs.meteor.com/api/pubsub Link to the Method docs: https://docs.meteor.com/api/methods
by troyjfarrell on 6/25/24, 5:42 PM
by kvonhorn on 6/25/24, 9:18 PM