Most active commenters
  • crabmusket(5)

←back to thread

Zero-latency SQLite storage in every Durable Object

(simonwillison.net)
285 points ajhit406 | 11 comments | 13 Oct 24 23:07 UTC | HN request time: 0.001s | source | bottom
Show context
stavros ◴[13 Oct 24 23:40 UTC] No.41832728[source]▶
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 need this, you don't need it, go with a boring Postgres database and a VM or something.

If you do know you need this, then you're kind of in a bind: It's not really very mature yet, as it's pretty new, and you're probably going to hit a bunch of weird edge cases, which you probably don't really want to have to debug or live with.

So, who are these systems for, in the end? They're so niche that they can't easily mature and be used by lots of serious players, and they're too complex with too many tradeoffs to be used by 99.9% of companies.

The only people I know for sure are the target market for this sort of thing is the developers who see something shiny, build a company (or, worse, build someone else's company) on it, and then regret it pretty soon and move to something else (hopefully much more boring).

Does anyone have more insight on this? I'd love to know.

replies(8): >>41832813 #>>41832877 #>>41832980 #>>41832987 #>>41833057 #>>41833093 #>>41833218 #>>41835368 #
1. crabmusket ◴[14 Oct 24 00:25 UTC] No.41832980[source]▶
As far as I can tell, multiplayer is the killer app for Durable Objects. If you want to build another Figma, Google Docs, etc, the programming model of Durable Objects is super handy.

This article goes into it more: https://digest.browsertech.com/archive/browsertech-digest-cl...

I think this old article is quite relevant too: http://ithare.com/scaling-stateful-objects/

Anyone who read the Figma multiplayer article and thought "that's kind of what I need" would be well served by Durable Objects, I think. https://www.figma.com/blog/rust-in-production-at-figma/

There are other approaches - I've worked in the past with CRDTs over WebRTC which felt absolutely space-age. But that's a much more complicated foundation compared to a websocket and a single class instance "somewhere" in the cloud.

replies(1): >>41833041 #
2. stavros ◴[14 Oct 24 00:35 UTC] No.41833041[source]▶
That's a very interesting use case. Given that your "players" aren't guaranteed to be local to the DO, doesn't using DOs only make sense in high-traffic situations again? Otherwise you might as well just serve the players from a conventional server, no?

CRDTs really do sound amazing, though.

replies(3): >>41833255 #>>41833274 #>>41834616 #
3. dumbo-octopus ◴[14 Oct 24 01:16 UTC] No.41833255[source]▶
In practice you’re most likely to be collaborating with other folks on your school project group, work team, close family, etc. Sure there are exceptions, but generally speaking picking a service location near your first group member ensures low latency for them (and they’re probably most engaged), and is likely to have lowish latency for everyone else.

On the flip side, picking US-East-1 gives okayish latency to folks near that, and nobody else.

replies(1): >>41833295 #
4. crabmusket ◴[14 Oct 24 01:18 UTC] No.41833274[source]▶
Best case, the players are co-located in a city or country, and they'll benefit from data center locality.

Worst case, they're not co-located, and one participant has good latency, and the other doesn't. This is equivalent to the "deploy the backend in a single server/datacenter" approach.

Aside from the data locality, I still find the programming model (a globally-unique and addressable single-threaded class instance) to be quite nice, and would want to emulate it even without the Cloudflare edge magic.

replies(2): >>41833340 #>>41834709 #
5. crabmusket ◴[14 Oct 24 01:23 UTC] No.41833295{3}[source]▶
And the corollary to that is that often your collaborations have a naturally low scale. While your entire app/customerbase as a whole needs to handle thousands of requests per second or more, one document/shard may only need to handle a handful of people.
6. paulgb ◴[14 Oct 24 01:27 UTC] No.41833340{3}[source]▶
> Aside from the data locality, I still find the programming model (a globally-unique and addressable single-threaded class instance) to be quite nice, and would want to emulate it even without the Cloudflare edge magic.

You might be interested in Plane (https://plane.dev/ / https://github.com/jamsocket/plane), which we sometimes describe as a sort of Durable Object-like abstraction that can run anywhere containers can.

(I'm also one of the articles you linked, thanks for the shoutout!)

replies(1): >>41833503 #
7. crabmusket ◴[14 Oct 24 01:59 UTC] No.41833503{4}[source]▶
I am interested, and I really enjoy your work on Browsertech! I haven't needed Plane above/over what Cloudflare is providing, but I've got it in the back of my mind as an option.

I've long hoped other providers might jump on the Durable Objects bandwagon and provide competing functionality so we're not locked in. Plane/Jamsocket looks like one way to go about mitigating that risk to a certain extent.

8. skybrian ◴[14 Oct 24 05:56 UTC] No.41834616[source]▶
Some games have regions and you only see players in the same region. For example, a “Europe” region. If you’re in the US and you connect to the Europe region, you know that you should expect some lag.

And it seems like that would work just as well with durable objects.

9. tlarkworthy ◴[14 Oct 24 06:15 UTC] No.41834709{3}[source]▶
It's the actor model essentially.

You can have a DO proxy each user connection, then they forward messages to the multipler document. The user proxy deals with ordering and buffering their connection message state in the presence of disconnects, and the document DO handles the shared state.

replies(1): >>41834801 #
10. crabmusket ◴[14 Oct 24 06:33 UTC] No.41834801{4}[source]▶
It's actors plus a global routing system that means all messages addressed to a unique identifier will arrive in the actor instance. I haven't seen any other actor frameworks that provide that.
replies(1): >>41836380 #
11. tlarkworthy ◴[14 Oct 24 11:10 UTC] No.41836380{5}[source]▶
Akka and Erlang both support distributed routing to their actors, but this is planetary scale and fully-managed out of the box, which is very cool.