The intent is that you'll be able to export multiple "entrypoints" to your worker under various names. So like you could have different routes on your zone use different entrypoints, for example. The "default" entrypoint is, well, the default, if you haven't chosen a named one.

at some point workers will be able to call other workers, and you could have a private entrypoint which is only exposed to some other worker, not to the public internet

ah, i see.

then i guess it's kinda weird that the default export is an object, but the named exports are constructors.

they are only constructors if they are implementing Durable Objects

named non-DO entrypoints would be objects with methods like

fetch

ah, i get it.

(personally i'd prefer a similar API since whether my worker is a DO or not is a bit of an implementation detail... similarly as how i'd like the KV and DO storage API to be closer).

but i see the distinction.

🙇

hmm, well, with durable objects you need somewhere to hang your in-memory state...

instantiating a class gives you a place for that

(personally i prefer closures for that, but it's just a personal preference. feels like the same reason that react et al are moving away from classes as an API)

hmm, how would that work?

not sure I understand what you mean

(but this is when there's just

fetch

, obviously)

I see, so the signature of DO entrypoints would still be different, in that the handlers would expect to receive a

state

first

in a curried fashion

yeah.

same for

env

, to be honest

it feels weird that it's on the request.

because it should be static for the life of the worker, no?

sort of. We have found some use cases where we really want to be able to vary parts of

env

per-request.

(mostly internal use cases)

but for durable objects,

env

is delivered to the constructor

so not per-request

so yeah, it would make sense to have

(state, env) => (request) => { ... }

hmmm. for me it's a bit annoying because i have for example AWS keys, and i need to instantiate aws4fetch every call instead of once.

Just my 2c purely on the naming: a class instance makes more sense in my head as a "Durable Object" than curried functions.