Right, but I saw that you had an example with rollup? Maybe that will work better than webpack?

I preferred rollup when experimenting with both, since the shim isn't required, but there's still a big reason to use webpack: when you want to use commonJS dependencies from NPM that rely on things that are different in an ES modules. ES modules are forced to run in strict mode, and their global scope behaves a bit differently, so some older NPM packages can have problems when running as an ES module. Rollup will still import CommonJS modules no problem, but it will convert them into an ES module in the process, and is unable to check if the module will be broken when that happens

Ah, good info! I'll play around a bit with my tsconfigs and rollup and see where I end up. 🙂

Thanks for the help!

No.

Unfortunately at the moment, the best documentation is wrangler source code for these APIs. The commits that added support for each new feature in wrangler (custom builds, modules, durable object bindings, and migrations) should all be atomic, so shouldn't be too tricky to find out where to look.

BTW, im just using ESBuild (instead rollup/webpack ) and works just fine. I can just target ES2020 and setup the format to ESM and done... (im using typescript primarily)

How much memory the DO has availabe? The same 128MB of memory of a regular Worker?

Yep 🙂

Noted, thanks!

@User Managed to get Typescript + rollup to work just fine by adding the

rollup-plugin-typescript

to the

rollup.config.js

and renaming all

*.mjs

to

*.ts

(and adding some types). 🙂

(using the

durable-objects-rollup-esm

as base)

there's no charge for reads that don't hit the storage API if you store the value in memory as @User suggested, your charges would likely be less than for KV as long as your data fit in memory and was accessed at least occasionally.

You're only charged for one request, for the inital connection establishment, and then for the wall clock time duration that the websocket is open.

Oh okey, that's awesome! 😁

Are we charged each time the durable object is instantiated? It would be great if we can have a price breakdown based on example scenarios

How are 2+ parallel requests billed in terms of compute (ex. the price per request), if they are processed by the same DO instance? Is it similar as Cloud Run billable time or each request is timed and billed on its own? https://cloud.google.com/run/pricing#billable-time

Hi, am following your webpack/commonjs sample (https://github.com/cloudflare/durable-objects-webpack-commonjs/tree/master/src) but getting an error when using wrangler publish. I've tried with and without --new-class GameStorage but I get this error message 400 Bad Request "message": "Uncaught ReferenceError: GameStorage is not defined\n at line 0\n" Any ideas? My shim file looks ok based on the sample: import bundle from 'index.js' const handlers = bundle.handlers const GameStorage = bundle.GameStorage export { handlers as default, GameStorage } And my index.js // In order for our ES6 shim to find the class, we must export it // from the root of the CommonJS bundle const GameStorage = require('./GameStorage.js') exports.GameStorage = GameStorage Thoughts?

Yes, it's the same as cloud run. Multiple requests won't execute at once, though, since durable objects are single threaded. While the other request waits, you'll just be billed one duration charge.

Got it, thanks! I was mainly interested about multiple open websocket connections to the same instance, whether they will be billed as one or each separately.

Yeah, you'll currently incur a duration charge as long as the connection is established, but it will be one duration charge shared across all messages.

just for clarity: requests to a single DO instance execute concurrently, but not in parallel. So you do still get the benefits of being able to do computations while waiting on outbound requests etc, but the execution therefore never overlaps so you're not being unfairly charged at any point 🙂

So in the end (for smaller scale of messages) it might make sense to have one DO instance keeping all the websocket connections open, while other DOs just invoke it on demand to send the messages out. 🤔

I mean you definitely could do that, but scale comes at you fast hahaha - you'd basically be giving up the whole autoscaled aspect of things along with basically pinning all of your requests to one point in the world so you'd also get increased latency

The real time updates are just something extra in our case, but still very nice to have. In the early stages it might save couple of bucks 🙂 This is all just theoretical though, looking forward to see real numbers I can calculate the real costs from.

To clarify, websockets are going to be used only as real time updates, only in one way - out. Other write/read requests are still going to be routed to the specific DO instances directly, with the only difference, the successful writes will also be sent out through the websocket - increased latency is totally fine here 🙂

@User we're working on the error messages for this case, but usually that indicates that your

GameStorage

class itself has an error in it, so the

require()

fails leaving the value as undefined

got it, will dig into that - thanks

actually seems like it might be some error in my index.js file...

Yes, looks like any initialization failure yields this error - so now running

npm run build

and

node /dist/index.js

regularly to catch any typos. Some better error handling here would be great. Thanks!