You can get your namespaces with

https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/workers/durable_objects/namespaces

an then send a DELETE to

https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/workers/durable_objects/namespaces/$NAMESPACE_ID

Using API auth as explained https://api.cloudflare.com/

When the NS is deleted you can delete the worker

Thanks, @User!

Hello, I'm new to DOs. Can I think of them like Workers just that they live one level behind the Workers (can only be accessed by Workers, not the open Internet) and have access to storage which actual Workers do not? I wonder if under the hood they reused much of the same infrastructure of Workers, i.e. Isolates.

ah, technically it's for an administrative task, but might as well try to use an object tbh

If we can think of DOs as different workers, then "Workers Store" would actually be a better name IMO. "Durable Objects" just seems really low level, talking about the implementation details. With "Workers Store" instead I can think of the store brand (the class, Starbucks as a company) and a single store as an object (instance of class, the Starbucks around the corner).

The main difference (IMHO) is that a random worker will be selected to serve any specific request, but you can control which DOs that worker will talk to. That makes the DO a single global point to do stateful computations. Storage (again, IMHO) is secondary to that idea, but it makes DOs even more powerful since you get fast persistence.

Thanks! So DOs are basically "unique stateful workers"?

That description makes sense to me, yes.

"Stateful Workers" would have been an apt name (and Unique is correct and even better)

It could still change name in beta, right? 😉

Quote from https://docs.temporal.io/blog/sergey-the-curse-of-the-a-word/ :

In my opinion, the Cloudflare folks made a pragmatic choice to call their (for all practical purposes) virtual actors "durable objects."

. Conceptually DOs are (virtual) actors. Naming them

unique stateful wokers

would sort of mean

unique stateful http controlers

which is just conceptually not what they are about. Check out this comment of Kenton in HN: https://news.ycombinator.com/item?id=24617551 , where the

actors

are discussed. That being said, I think the naming is just elegant. What I miss though, is mentioning of actor model itself. I totally understand why it's not done in official docs (the same reasons that are mentioned in the blog post I shared in the beginning of this message), but in this channel i'd love to see

actor model

mentioned more often, as many of the theory and patterns that are possible to implement with DO is just patterns of actor model. For instance, am currently reading https://www.amazon.com/Reactive-Messaging-Patterns-Actor-Model/dp/0133846830 and playing with

akka

framework just to get broader picture of what can be achieved with DOs.

I thought I heard somewhere that workers themselves are called actors internally inside cloudflare, or maybe just DO? naming is hard : )

I certainly wasn't there when the decision was made to call it Durable Objects, but I vaguely remember there was some pushback from people to use the term actor because DOs don't have the concept on an inbox, which actors frequently have. (But I personally don't think is a defining trait for actions, but oh well)..

Durable Object is also much smarter from a marketing POV.. which is probably the real reason why it was chosen 🙂

yeah, we were going to call them "actors" but we noticed that everyone who was familiar with the actor model ended up getting more confused than enlightened by it, very much like Sergey Bykov's experience (that @User linked above). I don't have any problem with admitting they are in fact virtual actors, as long as people aren't going to then expect to see supervision trees or whatever.

Nobody really loves the name "durable objects", but one thing I do really like about it is that we're using "object" in the object-oriented-programming sense, which I think is the right mental model for people to have when thinking about Durable Objects.

Hey everyone, congratulations and thanks for the amazing work at workers and Durable Objects

Durable Objects, for what I understand, are quite alike what in Elixir is called an _Agent_; that is, a process whose main purpose is to keep state (but, of course, outside the confines of a single server and the Erlang Virtual Machine)

There were talks and code sketches https://github.com/pragdave/component by Dave Thomas that didn't gain much traction within the Elixir community, but are very much aligned with what I believe are Durable Objects' current direction: splitting your application in many independent, isolated "units of logic" (he actually mentions global distribution as the upcoming paradigm), which, in turn, I believe, are very much aligned with OOP in the original, Smalltalk-like sense. Both are very interesting.

Anyways, thanks again for your work (using workers in production already!) and good luck!

Hah... "Agents" was a name we considered. My argument for it was that "Workers" do whatever random work comes in the door while "Agents" are assigned specific long-term workloads. But other people on the team didn't like it...

At this point in my little ChatroomDurableObject I am creating a new WebsocketPair every time a worker connects. This websocket is used to send real-time messages to the workers subscribed. Would it be possible to just create a single WebsocketPair in the constructor of my DurableObject and sent the same 'client' back to all the workers 'subscribing' to it?

Hi guys! Nice to meet you and glad to be part to this amazing project.

I have one Q which I cannot find an answer to: if we've used

idFromName()

to generate the object id, is there a way to get that "name" back? I thought that

idFromString(hexId)

would do this but it seems like it doesn't cause it's returning an empty object. Any ideas?

AFAIK, once a name is used to generate an ID, it can't easily be converted back. If you need it again, you could store the name somewhere else.

Yeah, we don't store your name string. You could send it to the object and store it in the persistent storage.

good to know 💪

OK who wants to make a Durable Object persistent storage backend replacement for this: 🙂 https://jlongster.com/future-sql-web