Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zero-latency SQLite storage in every Durable Object

simonwillison.net

Post reply on HN
Print view View original

71–80 of 108 posts

Re: Zero-latency SQLite storage in every Durable Object

#71

Post by ec109685 »

tmikaeld wrote: post #70
firtoz wrote: post #68

Earlier quoted context omitted.

AFAIK the writes and reads are done only from the same process, so the long term storage will apply only if the current process is hibernated. When you write something and then read it, it's immediate, because the writes and reads are also updating the current process's state in memory. For another process (e.g. another DO or another worker) to access the data, they need to go through the DO which "contains" the data…

You're right that reads and writes are immediate in the same client connection, this is how it works with CF KV as well - but not across the entire network. On KV they expect up to 30 second latency before a write can be written everywhere, I expect similar here.

Cloudflare ensures all operations on a DO happen on _the_ single instance of that DO, worldwide.

There’s no such thing as the read after wrote problem because only one host will ever do reads and writes (until that host dies).

Re: Zero-latency SQLite storage in every Durable Object

#73

Post by ec109685 »

_1tem wrote: post #67

What I don’t understand is why, in the example of flight seat mapping provided, you create a DO per flight. So does a DO correspond to a “model” in MVC architecture? What if I used DOs in a per-tenant way, so one DO per user. And then how do I query or “join” across all DOs to find all full flights? I guess you would have to design your DOs such that joins are not required?

They support “function” calling between DOs, so you are able to compose a response from more than one DO.

Re: Zero-latency SQLite storage in every Durable Object

#74

Post by camgunz »

stavros wrote: post #3

This is a really interesting design, but these kinds of smart systems always inhabit an uncanny valley for me. You need them in exactly two cases: 1. You have a really high-load system that you need to figure out some clever ways to scale. 2. You're working on a toy project for fun. If #2, fine, use whatever you want, it's great. If this is production, or for Work(TM), you need something proven. If you don't know you…

First, this is very insightful--I think most people should go through this exact analysis before architecting a system.

As others have said, the use is multiplayer, and that's because you need everyone to see your changes ASAP for the app to feel good. But more broadly, the storage industry has been trying to build something that's consistent, low latency, and multiuser for a long time. That's super hard, just from a physics point of view there's generally a tradeoff between consistency and latency. So I think people are trying different models to get there, and a lot of that experimentation (not all, cf Yugabyte or Cockroach) is happening with SQLite.

Re: Zero-latency SQLite storage in every Durable Object

#75

Post by djtango »

jwblackwell wrote: post #72

Does anyone else struggle to wrap their head around a lot of this new cloud stuff? I have 15+ years experience of building for the web, using Laravel / Postgres / Redis stack and I read posts like this and just think, "not for me".

From the article:

> For useful background on the first version of Durable Objects take a look at Cloudflare's durable multiplayer moat by Paul Butler, who digs into its popularity for building WebSocket-based realtime collaborative applications.

First apps that come to mind that have RT collaboration:

- Google Docs/Sheets etc

- Notion

- Miro

- Figma

These are all global scale collaborative apps, I'm not sure a Laravel stack will support those use cases... Google had to in house everything and probably spearheaded the usage of CRDTs ( this is a guess!) but as the patterns emerge and the building blocks get SAASified, mass-RT collaboration no longer becomes a giant engineering problem and more and more interesting products get unlocked

Re: Zero-latency SQLite storage in every Durable Object

#76

Post by ngrilly »

emadda wrote: post #21

Some other interesting points: - The write api is sync, but it has a hidden async await: when you do your next output with a response, if the write fails the runtime will replace the response with a http failure. This allows the runtime to auto-batch writes and optimistically assume they will succeed, without the user explicitly handling the errors or awaits. - There are no read transactions, which would be useful to…

> The write api is sync, but it has a hidden async await: when you do your next output with a response, if the write fails the runtime will replace the response with a http failure. This allows the runtime to auto-batch writes and optimistically assume they will succeed, without the user explicitly handling the errors or awaits.

It reminds me of PostgreSQL's commit_delay, even thought it's not exactly the same principle: https://www.postgresql.org/docs/current/runtime-config-wal.h...

Litestream, mentioned in the post, is also suggesting a similar technique.

Re: Zero-latency SQLite storage in every Durable Object

#78

Post by blixt »

I'm constantly impressed by the design of DOs. I think it's easy to have a knee-jerk reaction that something is wrong with doing it this way, but in reality I think this is exactly how a lot of real products are implicitly structured: a lot of complex work done at very low scale per atomic thing (by which I mean, anything that needs to be transactionally consistent).

In retrospect what we ended up building at Framer for projects with multiplayer support where edits are replicated at 60 FPS while being correctly ordered for all clients is a more applied version of what DOs are doing now. We also ended up with something like a WAL of JSON object edits so in case a project instance crashed its backup could pick up as if nothing had happened, even if committing the JSON patches into the (huge) project data object didn't have time to occur (on an every-N-updates/M-seconds basis just like described here).

Re: Zero-latency SQLite storage in every Durable Object

#79

Post by dumbo-octopus »

ec109685 wrote: post #71
tmikaeld wrote: post #70

Earlier quoted context omitted.

You're right that reads and writes are immediate in the same client connection, this is how it works with CF KV as well - but not across the entire network. On KV they expect up to 30 second latency before a write can be written everywhere, I expect similar here.

Cloudflare ensures all operations on a DO happen on _the_ single instance of that DO, worldwide. There’s no such thing as the read after wrote problem because only one host will ever do reads and writes (until that host dies).

Indeed. The entire purpose of DO’s is essentially to provide the consistency guarantees that KV cannot.

Re: Zero-latency SQLite storage in every Durable Object

#80

Post by fastball »

djtango wrote: post #75
jwblackwell wrote: post #72

Does anyone else struggle to wrap their head around a lot of this new cloud stuff? I have 15+ years experience of building for the web, using Laravel / Postgres / Redis stack and I read posts like this and just think, "not for me".

From the article: > For useful background on the first version of Durable Objects take a look at Cloudflare's durable multiplayer moat by Paul Butler, who digs into its popularity for building WebSocket-based realtime collaborative applications. First apps that come to mind that have RT collaboration: - Google Docs/Sheets etc - Notion - Miro - Figma These are all global scale collaborative apps, I'm not sure a Larave…

Google actually uses OT for their collab.
Post reply on HN