^ @User, @User

Personally, I do prefer DO in separate script, as it nicely allowed me to separate the “storage” logic. And also because I was lazy to make the wrangler work so I could bundle it with the non-DO handler 😅

I am also calling the DO from two different workers, so I think I will continue to prefer this way

Personally, I'm pretty indifferent. Doesn't affect me or my developer experience either way, really. (Not sure what the behavior is right now because I've only done worked with them in a single script), however, the one thing I would say is that if DO classes are all their own scripts, it would be nice if either they didn't count towards the limit of 30 Workers scripts per account, or if that limit was raised. Otherwise, it'll be very easy to hit that.

I didn’t realise the number of scripts, that’s a good point which would force me to reevaluate it sooner or later

pretty much always separate, but i bundle using deno before uploading (ie, i don't use Workers modules, since I also import URLs and don't want to have to manually walk the dependency tree to figure out what needs uploading).

Wait so do you upload/deploy it as one script or multilpe?

one script (and one metadata.json file).

but in my project it's several scripts.

I see. Yeah what I was really getting at is whether people like to have multiple named workers in production, one which implements the class, and one which calls it

the top-level file for my latest worker looks like this:

(i implement the top-level worker as a class for consistency with everything else)

makes sense

Hmm, why do you prefer multiple? To me it feels like you'd commonly end up developing and deploying changes to the caller and the class at the same time, and it'd get cumbersome to coordinate multiple deployments.

Same here (without that Worker class stuff)

Yeah, I'd agree. Because they're all doing related stuff, if they had to be separate scripts, I'd have them all in a mono-repo anyway. Each script would just have it's own

wrangler.toml

. If one of the deployments failed for some reason, I guess that could be annoying, because I could get into an inconsistent state where the Worker script is expecting something different of the DO class script (or vice-versa).

@User, since worker logic and DO logic are in the same file, does that mean unused worker logic is shipped to the DO and vice versa?

(it feels weird to export a class that is never instantiated by the code that includes it.)

personally, i think there's an opportunity for workers to use module syntax to avoid this boilerplate, by providing access to related CF resources through

import

.

ie, something like:

js
import {teams} from '.env'

export default request => {
  let id = teams.idFromName('some-name')
  return teams.get(id).fetch(request)
}

Yes, the script will be parsed in full in both locations. But I don't think that's likely to make a lot of difference in practice.

I didn’t jump all in for implementing DO classes into existing Workers, I rather created new DO Worker instead that’s used/called by API (2 envs) and Status Page workers. It will get different once I will also need to separate the DO storage same as the API envs, then I will be looking into bundling and deploying them together I am no expert, but happy to talk about my use case, we just need to sync our timezones 😀

The initial idea was to call the api worker from the status page one, but that’s not allowed/working yet, so it’s calling the DO directly

a) I'd like to add +1 to @User statements: "Personally, I do prefer DO in separate script, as it nicely allowed me to separate the “storage” logic." and "I am also calling the DO from two different workers, so I think I will continue to prefer this way". I think it depends on a project, but I find myself thinking about DO in similar manner. b) I'd add that if one DO namespace can be bind to multiple non-DO handlers - it automatically implies that it would at least optionally be possible to separate the DO script. I.e. In MVC world when Database/API is called from two different apps, db preferably should be logically separated from both apps. c) My feedback to poll's question would be: I would want both options on the table and prefer to be able to make this choice on ad-hoc/per-project basis. Argumentation for my answer in c): c1) It's identical question for me as "should frontend(ie. react) and API be in single repo, deployed at the same time, developed by same team, etc. etc.". Or "monolith VS microservices". The answer always is same - it depends. c2) My toy project with DO, currently only hello world https://cerkasas.com/, is single repo/two files/two Worker scripts. My deployment of https://github.com/cloudflare/workers-chat-demo is single repo/single file/single script. I bet i'll be using multiple combinations of repo structure/file structure/WorkersScripts count along the way. c3) There are so many factors that will influence my decision: c31) If it's quick proof-of-concept hack I work on, I might prefer to choose single script, so it's quicker/simpler/does not pollute Workers script list. c32) With the DO functionality I have in mind implementing in my startup project, at least now I guess i'll surely treat it as a separate architectural pieces of my system, and therefor separate repos, separate sections in documentation hub, maybe - developed by different team members(as is the case with front/back logic), so - separate Worker scripts..

In docs you probably can present both approaches as equally good&working, or pick the one we think might be easier to grasp for newbies. Though wrangler templates/boilerplate repos will still probably have to suggest single approach as a 'more preferred one when you start a new project' - and I am not sure what I'd prefer. Single script is less hassle on one hand. On another - two scripts, and therefore logical separation of concerns, gives a lot of clarity about what's happening under the hood. Really torn on this question, haha.

Ah, so if you had the ability to call worker-to-worker more generally, does that change things? Do you think you'd still have one worker calling another worker's DOs directly, or would it call the other worker's top-level handler which would then do the routing to the correct DO?

I would call the API Worker instead of calling it’s DOs directly. The DO underneath can change to anything else and the clients (in my case the status page render worker) would not need to care.

@kenton Is there something specific you are trying to decide from the design/technical point of view?

Yeah, basically I think the current model where "durable object namespaces" are a first-class entity separate from scripts is not working well, especially when classes are defined in the same script from which they are called... it's weird that you have to upload the script, then create the namespace bound to it, then upload the script again to create the binding