yeah, as long as this is a string => function map, classes definitely make more sense.

one last thought: maybe the best API for DO is EventTarget? https://developer.mozilla.org/en-US/docs/Web/API/EventTarget

ie, piggyback on EventTarget for DO like you did on Service Worker for Workers.

(this to me is more explicit and less bespoke than method names called by convention.)

eh... we are moving away from EventTarget because of problems it has, e.g. awkward support for events that expect a response, no support for async event handlers, etc.

ah, of course. that makes sense. always a delicate line between familiarity and flexibility.

DOs looks like a great product! I was wondering about the feasibility of building a serverless database with DOs and how it compares to using something out-of-the-box like FaunaDB. How would I go about ensuring ACID compliance, authorizations and a query language?

@User , @User - great discussion, enjoyed reading through! Thanks!

I don't want this to go unanswered. So I'm not an expert, or in the DO beta, but I think I can give a reasonable answer. DO provide the building blocks you could use to build a serverless database, but keep in mind that a product like FaunaDB took an expert team of dozens a few years to build. Even though DO provides you with the building blocks, it will still be a huge undertaking that shouldn't be underestimated. I guess it's like someone gives you a bunch of bricks, steel and wood. It will be difficult to build a skyscraper even though you have the materials, but you may be able to build a house, even by yourself.

That's correct. Though building a database on top of Durable Objects should be easier than building it from scratch on classical servers / disks. DO handles low-level storage concerns like disk I/O, durability, machine failover, distributed consensus, etc. What's still up to you is implementing a query language and other semantics specific to your type of database. Roughly, half the problem is solved, but the other half is still a big problem.

Can it be assumed that CF will also be addressing that other half for general use cases at some point?

There are many ways to address "the other half". Do you want a relational database (SQL)? Document database? Graph database? A Reddis-like KV store? Cloudflare is not likely to build all of these, but might build some. In particular I think it's a safe bet we'll be improving performance of Workers KV by using Durable Objects.

And keep in mind many applications may find it easier and faster to build directly on Durable Objects rather than use a database built on top. It sort of depends on what you're doing. Do you have one monolithic dataset you want to query across, or do you have many small (per-user, per-document) datasets? If you have many small datasets, putting them in a monolithic DB will probably slow you down.

I just read Pat Helland's Life Beyond Distributed Transactions (https://queue.acm.org/detail.cfm?id=3025012) and it's very in line with this aspect of DO. I wonder if you could have an architecture that let's you opt-into larger DB like constraints on a per object basis.

Any eta on getting

waitUntil

support in the new es module syntax?

re: beta limitations -- are there any limits on request rate? @User

i mean, the wording "not exceed 1 GiB of storage. If you exceed or approach this limit rapidly, your access may be temporarily or permanently cut-off" sounds rather scary, but not like "could happen in 5 minutes" and accidentally making a ton of requests sounds much easier 🙂

to a single object, tens to low hundreds of RPS

this and the storage limits aren't a hard limit, though. the storage limit is a fail-safe if you might affect other users - it shouldn't be scary 🙂

ah I see, thanks)

it just landed last week, but only in the DO, not in the parent worker: https://discord.com/channels/595317990191398933/802187271067140107/807309699544121384

That’s awesome, but I’m waiting for support in the parent worker 😕

Gotta get my passive caching back 😁

yeah, they're figuring out where to hang that API: https://discord.com/channels/595317990191398933/773219443911819284/808364668149694465

Good to know. Thanks! 🤞

Is there a form anywhere for registering interest for Durable Objects?

aha, found it on the blogpost

Are the es module syntax workers subject to any beta limitations? I assume not but it’d be good to know

They're in beta, but there aren't any limitations beyond the fact that we may change the API