exploring the idea of having DO namespaces be owned by the script itself rather than a separate thing, which seems to simplify a lot in this case

but wanted to check whether other people are actually using durable objects this way. If you usually put classes in a separate script from the caller, then namespaces being separate from scripts makes more sense

also there's been some debate about whether the UI should show all worker scripts in one list, or should attempt to split DO-implementing scripts from "regular" scripts.

Got it, if DO would be owned by the script itself, would it still be possible to share/bind it to another workers? 🤔

we could still allow cross-worker bindings. But instead of specifying a DO namespace to bind to, you'd specify a target script+class name pair.

but also, we're kind of wondering if cross-worker DO bindings are necessary if worker-to-worker exists in general

Good point

I tend to think that each worker script should be interpreted as a microservice (or... "nanoservice"???). You split services to be able to deploy them independently, but those splits may or may not correspond to where you split ingress logic from DO logic.

in fact, the service which owns the DOs might want the ability to, say, put a caching layer in front of them... which it can't do if other services are calling directly into its DOs without going through an ingress layer

This is actually something I wanted do, but left for later because I didn’t want to put the caching logic to DO but rather keep that in the ingress layer

(aside: we really need to come up with the right term to identify the non-DO fetch handler part of a worker, separately from DO classes... it's difficult to talk about currently for lack of the right words)

The thing I like about binding DO namespace to Workers is the fact it is not accessible for others (either workers or internet). I would need to expose it with putting “ingress” in front of DOs if I want to make worker to worker request, right? Or is there any plan to somehow “bind” workers between each other internally?

I think the way we'd enable worker-to-worker is you'd define a binding representing the other worker, so you'd do

env.otherWorker.fetch(request)

to send a request to it. No need to map to a public URL.

That would be just perfect

That's something I would love to see

Not just for DOs, right? 🙂

Yeah in general, being able to make workers that can only be accessed by my other workers would be amazing

(As a native method of course)

yeah, this is an instance where capability-based security makes life a lot easier. Instead of exposing a service to the world, then adding measures to authenticate clients... just expose the service directly to the clients who are supposed to have access and no one else, and forget about authentication...

Exactly, if I have to add authentication to every worker, then I'll never go fully down the nano services route, because it doesn't scale

By letting CF do the work for me, I don't have to worry

Yep, would make my life a lot easier. Sign me up for worker to worker requests beta 😅

The more I think about such approach, the more I like it: a) Pushing DO towards an "advanced feature of a Worker script" instead of "storage of a specific kind that is implemented as separate worker script" (if that is indeed what the intention are) is indeed easier to grasp; Only pure storage with namespace bindings remains KV - clear. b) Reducing first-class citizen count of a platform simplifies platform itself - great, especially for newcomers. c) Problem of how to represent scripts in UI is also gone; d) Cross-worker calls allows for any architecture you want, and if you want separation if concerns in terms of projects/repos/etc. -> you just have two projects and name worker scripts accordingly. Does the job. e) I'd then also question if 'we could still allow cross-worker bindings' is still relevant. Such bindings again introduces additional complexity which is just duplicating what worker-to-worker calls are achieving anyways. Many PROS, can't think of any CON. DO becoming 'less of the first class citizen' is hardly a CON - it's still an advance feature you start exploring only after warming up with platform. Not sure if I interpreted your described approach correctly. And also my knowledge of DO is very limited. But at least as of now - my big bold +1 for this 🙂

Thanks for all the great feedback @User @User @User @User @User !

My 2 cents regarding worker-to-worker and including the DO use case: I like the idea of having service bindings instead of just some sort of free-for-all. Maybe more like a service mesh, which allows for service-to-service policies and observability.

Being able to see workerA called WorkerB x number of times, and even apply rate limiting or maybe even retry policies could be cool.

Personally for me "DO namespaces be owned by the script itself rather than a separate thing" + "worker-to-worker" calls + great @User insights and suggestions, in terms of development experience, in a way sums down to 6 topics - structured them in a spreadsheet:

Quit some things to think through/discuss. Yet I still really love such approach - this way workers platform gets two awesome advanced features - DO(scoped at script level) and Cross-worker calling(does not matter if we title that scope script or platform level) - and without introducing new first class citizens we keep the initial platform (onboarding) simplicity intact, which I personally feel is a lot to cherish and value. UI maintains it’s simplicity as well, advanced features appear in advanced sections, where they belong. That’s at least the way I see it with my limited knowledge on what actually can/could/is planned to be implemented.

waitUntil()

is indeed available within the context of a DO (https://developers.cloudflare.com/workers/runtime-apis/durable-objects#durable-object-class-definition) as

state.waitUntil()

ahp looks like someone beat me to it lol