81–90 of 98 posts
what's the maximum qps that a single durable object can handle?
An object is limited to one thread. How many qps that is depends entirely on what your app does, since the app can run arbitrary code in the request handler...
Can the data store only store alphanumeric or can you write blobs? Could a chat app store uploads inside the object?
Earlier quoted context omitted.
"Actors" was actually one of the names we used internally for a long time (it's still all over the code), but eventually decided against because we found that people familiar with the Actor Model actually expected something a bit different, so it confused them. But yes, the basic idea is not entirely new. For me, Durable Objects derive from my previous work on Sandstorm.io, which in turn really derives from past work…
> ...we found that people familiar with the Actor Model actually expected something a bit different I haven't done any programming with Actors per se but after skimming over its Wikipedia entry and other blog posts, Durable Objects does sound a lot like Actors to me. Genuinely curious: What were some glaring differences that you were made aware of that led to not naming it Actors? Thanks.
So ironically it seems like many people expected statelessness to be a property, which is the opposite of what we were going for!
Disclaimer: I haven't worked with Erlang myself and I'm probably missing some nuance here. My background is in object-capability systems, which also commonly claim to be actor systems, and match what we're doing very closely.
Earlier quoted context omitted.
> ...we found that people familiar with the Actor Model actually expected something a bit different I haven't done any programming with Actors per se but after skimming over its Wikipedia entry and other blog posts, Durable Objects does sound a lot like Actors to me. Genuinely curious: What were some glaring differences that you were made aware of that led to not naming it Actors? Thanks.
So, this would be a better question for someone who has actually worked with other actor-model frameworks. But, one sense that I get is that in Erlang, there is a design philosophy where most actors are intentionally stateless so that if anything goes wrong they can die and be replaced easily. So ironically it seems like many people expected statelessness to be a property, which is the opposite of what we were going…
Is there only a single instance of the example Counter object globally and as there are no additional await'ed calls between the get and put operations, the atomicity is guaranteed? Is the object then prevented from getting instantiated on any other worker? Can this result in a deadlock if I access DurableClass(1), then delayed DurableClass(2) in one worker and DurableClass(2) and delayed DurableClass(1) in another w…
However, memory corruption via manual memory management and deadlocks via manual locking are commonly caused by simple and innocent programming mistakes and basically something one has to live with on a day to day basis.
Is this not sharding?
I cannot find any word on pricing, is it included in the regular workers $5/mo plan?
For those in the beta, it's currently free. We are still working out what pricing will look like post-beta. We realized we need to see how people actually use it and get some feedback before we could settle on the right pricing structure... that's what betas are for.
Earlier quoted context omitted.
For those in the beta, it's currently free. We are still working out what pricing will look like post-beta. We realized we need to see how people actually use it and get some feedback before we could settle on the right pricing structure... that's what betas are for.
Would something like a tinyurl clone also be a good use case for this? On a first hand look, it does look good.
Wow, very cool! I didn't see the string "mobile code" in this press release, but that's essentially what this is, right? Automatically moving objects to be near the computation that needs it, is a long-standing dream. It's awesome to see that Cloudflare is giving it a try! Plus, the persistence is clever - I'm guessing that makes the semantics of mobility much easier to deal with. I love the migration to nearby edge…
> Have you given any thought to automatically migrating Durable Objects to end user devices? We don't have any current plans, but... I was the co-founder of Sandstorm.io before going to Cloudflare, and Durable Objects are very much inspired by parts of Sandstorm's design. So yeah, I've absolutely thought about it. ;) It would definitely have to be an opt-in thing on the developer's part, due to the security considera…
Earlier quoted context omitted.
Would something like a tinyurl clone also be a good use case for this? On a first hand look, it does look good.
Although if the object is single threaded too many reads might overload it. Or is the object then replicated?