I think we could make it possible to use a class as your main worker entrypoint (not DO), and then

env

would be passed to the constructor instead of each handler call

yeah, aligning those APIs would make it easier to onboard folks.

(i think)

well, at one point that is what I proposed, but a lot of feedback suggested people were put off by having to declare a class rather than a function. But in the case of Durable Objects specifically, classes make more sense, since objects are instances of classes in OOP

i guess it comes down to whether you see DOs as

stateful workers

or

workerful states

, haha.

once you have more than one method/function, classes definitely make more sense.

also, outside of durable objects, the lifetime of any particular instance of this class, and which requests get routed to it vs. other instances, would be totally arbitrary

which is fine for people who get it, but maybe confusing for some

for non-durable-objects, we really want people to think of each request as being handled by a new worker independent of any other... global variables currently break that abstraction, but we might change that someday

yeah, it's hard to anticipate when your potential users are so broad.

lot of folks used to server stuff, but also very accessible to front-enders.

i think react has taught a lot of folks about immutability

so i think closures are kinda natural in that sense.

I might go ahead and make it possible to use a class to implement a regular (non-DO) worker, but it would be optional and probably not what we show in beginner documentation

Out of curiosity do you have an FP background? 🙂

i'm not sure... i like FP in JS a lot but am not dogmatic about it.

basically front-end frameworks seem to be moving towards FP, so seems maybe a good wave to ride in terms of API design.

users know that a view is rerendered when its state changes, so makes sense that a worker would be redeployed when its env changes, for example.

anyway, sorry to get a bit academic.

workers are awesome. and to me DO are to server what react was to client.

rethinking how things are organized.

ie, before react you had CSS, HTML, and JS in their own silos.

react said let's colocate those per component.

before DO, you had compute, network, and storage in their own silos (lambda, API Gateway, dynamo).

DO said let's colocate these per instance.

it's really nice.

oh I just realized what you really meant with the

state =>

closure earlier... it works well as long as there is only one handler (

fetch()

), but I've been thinking in terms of multiple handlers all along.

right

we actually have three types currently,

fetch()

,

scheduled()

, and

trace()

(which is not available publicly yet)

and plan to add others