41–50 of 159 posts
Hey hacker news! I'm one of the people behind this, happy to answer any questions.
What does this mean for Replicache development, is the client-side codebase mostly shared and can expect continued updates, or more likely to replace the primary focus for you?
Hey hacker news! I'm one of the people behind this, happy to answer any questions.
Congrats! I've been watching this space for a while, having built a couple multiplayer sync systems in the past in private codebases, including a "redux-pubsub" library with rebasing and server canonicity that is (IIUC?) TCR-like. There's a lot to like about this model, and I find the linked article quite clear - thank you for writing and releasing this! 1. You wrote "For example, schema validation and migrations jus…
2. This is what I want to work on next. I am similarly intrigued by the Prosemirror model. It seems like a good match.
If you want true concurrency, in an elegant format, with a lot of the common problems abstracted away -- use Erlang. They solved this 30 years ago.
Specifically does BEAM build in a data structure for preserving user intent while multiple users type/delete/apply styling in the same text field?
Earlier quoted context omitted.
What does this mean for Replicache development, is the client-side codebase mostly shared and can expect continued updates, or more likely to replace the primary focus for you?
The clients are almost entirely shared. We will continue to develop Replicache. https://x.com/replicache/status/1714684061589877235?s=20
Any idea how this compares to Supabase's Realtime & Presence libraries? https://supabase.com/docs/guides/realtime
We'll post something soon comparing all of the options (in our opinion). But as I understand it: - Supabase Broadcast: one client sends every other client a one-time message - Supabase Presence: one client tells all other clients that its own state has changed. This is similar to above, except that server keeps track of all the last-state for each client so that new members of the channel can get up to date. - Supaba…
Supabase’s real-time stuff lets various parts of your system send messages about changes to each other. But when it comes to realtime editing, that’s the easy part!
Reflect is a much higher level abstraction that handles the hard parts:
- maintaining a cache on the device (this alone is annoying hard to get right)
- queuing updates to send to the server reliably
- handling conflicts between different users while preserving the intent of each user, by rebasing histories locally, and choosing the winner on the server
Very allagmatic. Instead of storing & transferring structures transfer operations. Iw as wondering what kind of checkingpoint or snapshotting there might be. Such that one doesn't have to "replay-the-world" if something goes awry (localstack persistence did/l (does?) this, storing state by just recording/replaying API calls). It sort of seems like having a globally accepted state is enough & makes sense, but it still…
If you want true concurrency, in an elegant format, with a lot of the common problems abstracted away -- use Erlang. They solved this 30 years ago.
Reflect could be built using Erlang. Erlang could not be used to replace what it does.
I need a simple explanation like i am 6 years old because i have a mind of a 6 years old.