Depends on the context in which they’re called TBH... the scope isn’t set, so if you call the function from inside another fn, that can hijack the “this”. Most simple examples don’t run into this. In React land, we used to have to do this in the constructor of every ES6 class component (till everything moved to stateless functional components)

If anyone needs to rebind internal DO methods to this, a bit of proxy magic in the constructor seems to solve it where a simple bind statement wont...

Also added an example for ES6 module syntax (required for Durable Objects) to the itty docs - nothing major, just pass the

env

as a second param to the request handle and the handlers will get it: https://www.npmjs.com/package/itty-router#cf-es6-module-syntax

please no, as tons of 3rd party libraries use date at init for timing etc etc, and you'd just end up with more polyfills that...return zero since you don't have anything else to return anyway

FWIW, i imagine more libraries (templates, et al) use

new Function

, which throws.

Hello guys, I have a question about pricing.

Price per request    $0.15 / MM

What does it mean for websockets? Does it mean every websocket message will be calculated as a new request? What does mean MM? Million?

For example I have two users in chat. Both send 10 messages 10*2 = 20 in total. Is it 20 requests or is it 2 requests?

Each established websocket connection = 1 request, so it does not matter how many messages you sent through it. However, there are charges for the compute time (basically the lifetime of the websocket connection) and bandwidth.

ok, thank you

lol i just looked at the source code for itty-router... clever use of the Proxy

Thanks! It's def turned me on to the crazy power/abuse of proxies 🙂

anyone know how to get the colo of an incoming DO fetch request? i.e. where the object instance is running? The request.cf is undefined for these calls.

It isn't currently exposed. I'm curious what your intended use for it is, if you don't mind?

For debugging mostly, identifying latencies due to the DO and calling script being in separate colos, and making sure partitions I expect to be running in the same colo as the caller (i.e. the "name" passed into

idFromName

contains the colo) actually are

For those that are interested in firing class methods directly on a stub (in other words treating it like a real class instance instead of a communication through fetch stub), I’m working on exactly that 🙂 internal API automatically generated...

Will publish code once I have a working example

woot, excited to see it!

a fix to the script upload validator was just deployed to give better errors for scripts written in the modules format (all durable objects scripts)

playground happen to support DO? (guessing not)

@User unfortunately no

No worries - thanks @User !

do you mean like this? or something else

js
class ZeroTwo {
    fetch() {}
}

export default new ZeroTwo();

ok, so I don't know if this will blow anyone else's minds, but i'm flipping out here. With this DurableObject:

and the abstraction/proxies I just wrote, I can allow for this sort of Worker interface to the durable:

persistence/initialization, etc all works out of the box - no need for internal DO routing, calling fetch, etc

verification of it in action:

gonna publish this ASAP so people can start playing with this streamlined interface to durables...

how are you getting the `await`able setter to work? 🤯

Proxy around the stub, watching both the get/set... each fires a corresponding fetch call behind the scenes, passing the args via request body - have a single router function embedded in the IttyDurable to automatically handle/route those calls 🙂

Awaits around everything because obv they’re firing async actions under it all. Not perfect but still way more readable, IMO