5 ms·

Hey hacker news! I'm one of the people behind this, happy to answer any questions.

by aboodman 3y ago

woggy 3y ago
Curious what your thoughts are on ElectricSQL?
- aboodman 3y ago
  It seems really interesting. The key thing to understand is that there are deep architectural choices made in each of these systems that really influence what you can do. There is "mechanical sympathy" with certain kinds of applications. ElectricSQL is a distributed database. It's not going to run anywhere near 60fps with tons of users, because it's not running in memory on the server like Reflect/PartyKit/Liveblocks do. OTOH it will allow you to filter/query interact with much more data at the same time than Reflect/PartyKit/Liveblocks do – Reflect has a limit currently of 50MB per room and it's not practical to have dozens of rooms open at one time to get around this. Systems in the Reflect room/document based model are well suited for applications where you primarily interact with one "document" at a time and you want that to be as realtime as possible. Figma is the canonical example. You want the entire document to move together at 60 FPS, completely fluidly. It's not going to be possible to do this well in the ElectricSQL model IMO. Spreadsheets, presentations and documents are other examples. Systems in the ElectricSQL model are more suited for applications where you are interacting with lots of documents at the same time. Think CRMs, bug trackers, etc. Of course real applications are messy. Even document editors always have a dashboard where you can at least see all your documents at once. And CRMs of course have a detail view that looks like a document editor. Both types of systems are going to track toward the other to support the needs of real applications. HTH!
coreyh14444 3y ago
Aaron is humble, so I'll do it for him! He created Greasemonkey and has had a hand in several groundbreaking browser innovations over the years.
- aboodman 3y ago
  :)
- case 3y ago
  Having worked with Aaron on a few things many years ago, I can confirm this as well!
nodoodles 3y ago
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?
- aboodman 3y ago
  The clients are almost entirely shared. We will continue to develop Replicache. https://x.com/replicache/status/1714684061589877235?s=20 https://x.com/replicache/status/1714684061589877235?s=20
  - nodoodles 3y ago
    Thank you! Really like Replicache though only used it for hobby projects so far, and enjoyed also the backend side of it (minimal and entirely in supabase stored functions, probably not prod ready). Hope the new approach is a great success for you!
jayunit 3y ago
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 just sort of fall out of the design for free." - very curious to read about what you've found to work well for migrations! I feel like there's a lot of nice stuff you can build here (tracking schema version as part of the doc, pushing migration functions into clients, and then clients can live-update) but I never got the chance to build that. 2. Do you have a recommendation for use-cases that involve substantial shared text editing in a TCR system? I'd usually default to Yjs and Tiptap/Prosemirror here (and am watching Automerge Prosemirror with interest). The best idea I've come up with is running two data stores in parallel: a CRDT doc that is a flat key/value identifying a set of text docs keyed by UUID, and a TCR doc representing the data, which occasionally mentions CRDT text UUIDs.
- aboodman 3y ago
  1. I hope to write about this soon! We've developed something we really like for Reflect. 2. This is what I want to work on next. I am similarly intrigued by the Prosemirror model. It seems like a good match.
chrisco255 3y ago
What is the maximum number of users that can be concurrently in a room?
- aboodman 3y ago
  There's no max enforced. Right now, it will fall apart pretty quick around 25-50, depending on how much work is going on. For the GA, we plan to implement a scheme that will allow the room to support up to ~100 concurrent active users (actually doing things) and thousands just watching.

Hey hacker news! I'm one of the people behind this, happy to answer any questions.

woggy 3y ago

Curious what your thoughts are on ElectricSQL?

aboodman 3y ago
It seems really interesting. The key thing to understand is that there are deep architectural choices made in each of these systems that really influence what you can do. There is "mechanical sympathy" with certain kinds of applications. ElectricSQL is a distributed database. It's not going to run anywhere near 60fps with tons of users, because it's not running in memory on the server like Reflect/PartyKit/Liveblocks do. OTOH it will allow you to filter/query interact with much more data at the same time than Reflect/PartyKit/Liveblocks do – Reflect has a limit currently of 50MB per room and it's not practical to have dozens of rooms open at one time to get around this. Systems in the Reflect room/document based model are well suited for applications where you primarily interact with one "document" at a time and you want that to be as realtime as possible. Figma is the canonical example. You want the entire document to move together at 60 FPS, completely fluidly. It's not going to be possible to do this well in the ElectricSQL model IMO. Spreadsheets, presentations and documents are other examples. Systems in the ElectricSQL model are more suited for applications where you are interacting with lots of documents at the same time. Think CRMs, bug trackers, etc. Of course real applications are messy. Even document editors always have a dashboard where you can at least see all your documents at once. And CRMs of course have a detail view that looks like a document editor. Both types of systems are going to track toward the other to support the needs of real applications. HTH!

coreyh14444 3y ago

Aaron is humble, so I'll do it for him! He created Greasemonkey and has had a hand in several groundbreaking browser innovations over the years.

aboodman 3y ago
:)
case 3y ago
Having worked with Aaron on a few things many years ago, I can confirm this as well!

nodoodles 3y ago

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?

aboodman 3y ago
The clients are almost entirely shared. We will continue to develop Replicache. https://x.com/replicache/status/1714684061589877235?s=20 https://x.com/replicache/status/1714684061589877235?s=20
- nodoodles 3y ago
  Thank you! Really like Replicache though only used it for hobby projects so far, and enjoyed also the backend side of it (minimal and entirely in supabase stored functions, probably not prod ready). Hope the new approach is a great success for you!

jayunit 3y ago

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 just sort of fall out of the design for free." - very curious to read about what you've found to work well for migrations! I feel like there's a lot of nice stuff you can build here (tracking schema version as part of the doc, pushing migration functions into clients, and then clients can live-update) but I never got the chance to build that. 2. Do you have a recommendation for use-cases that involve substantial shared text editing in a TCR system? I'd usually default to Yjs and Tiptap/Prosemirror here (and am watching Automerge Prosemirror with interest). The best idea I've come up with is running two data stores in parallel: a CRDT doc that is a flat key/value identifying a set of text docs keyed by UUID, and a TCR doc representing the data, which occasionally mentions CRDT text UUIDs.

aboodman 3y ago
1. I hope to write about this soon! We've developed something we really like for Reflect. 2. This is what I want to work on next. I am similarly intrigued by the Prosemirror model. It seems like a good match.

chrisco255 3y ago

What is the maximum number of users that can be concurrently in a room?

aboodman 3y ago
There's no max enforced. Right now, it will fall apart pretty quick around 25-50, depending on how much work is going on. For the GA, we plan to implement a scheme that will allow the room to support up to ~100 concurrent active users (actually doing things) and thousands just watching.