That can work?

I don't know. I am trying now. Will let you know if I succeed.

Still trying to learn more about DO and how to use them. There is a demo repo that attempts to demonstrate basic usage of DOs (link: https://github.com/cloudflare/durable-objects-rollup-esm/tree/master/src ). When I run it locally I can get the value of A and B by opening browser and hitting http://localhost:8787/?name=A (or B) but don't know how to increment the value of A or B. I tried http://localhost:8787/increment and http://localhost:8787/A/increment and many other variations. Can someone please advise what the url or path should be to increment or decrement the value of A or B? In general how do I interact with DO? In the docs it says that mostly it is done via a worker but still I don't understand how that works

try http://localhost:8787/increment?name=A

that worked, thank you Larry!

Just wanted to say hi and a huge thanks to the Workers team for creating Durable Objects. I'm using them for a prototype of a realtime editor and they're just a joy to work with. I really hope other cloud vendors steal this idea mercilessly as soon as possible, because I think it's a great innovative programming model ;). It reminds me of this excellent article http://ithare.com/scaling-stateful-objects/ Anyway, it's been great lurking here and seeing people discuss some of the caveats to be aware of (that 128MB shared memory limit is slightly scary) and get some knowledge. Hopefully once my prototype goes live I'll be able to share experiences of my own. Our current architecture is using DO storage for "important but temporary" state, and persisting the long-term data, including historical revisions etc., in AWS S3. Not sure if that's a daft idea, but it was simple to get working thanks to https://github.com/mhart/aws4fetch. The DO makes an excellent coordination layer on top of S3 to ensure there's a single writer to the filesystem.

Just trying to see if DO will work for my project. I cloned this template to VS Code and was able to run the sample with wrangler dev quite easily (thank you cloudflare for that). https://github.com/cloudflare/durable-objects-typescript-rollup-esm However, the DO storage doesn't seem to be persisting from call to call. I do /increment?name=1 and if I console log in several places I can see that after doing a put, the value has incremented. But if I then issue another call, it shows this line at the beginning of the fetch method starting with 0 again

let value: number = await this.state.storage?.get("value") || 0;

is there something else I have to do to get my local environment to persist?

If you're not restarting the local dev environment it should persist in memory. You could try adding the

--persist

flag to the wrangler dev command to make it persist over restarts though.

I think there's something weird with DOs where every time the code changes it refreshes them in dev

but yeah the persist option might help that

Hey, thanks, that --persist flag if what did it. For some reason in VSCode on Windows at least, without the persist flag, each call starts fresh

Thanks, this did it!

Trying to understand fully how this all works using the sample app. I see that calls to the Durable Object go through the fetch method:

async fetch(request: Request) {

And the fetch method is called by the worker index.ts as follows:

let resp = await obj.fetch(request.url)

What I don't understand is that request.url is a string but the signature of the Durable Object fetch method requires the parameter to be an instance of a Request. How does this work?

Fetch accepts a URL or a Request object

Then the DO receives that inbound request as a Request object

Ah, so there is some sort of "middleware" between obj.fetch and the actual defined fetch method on the DO which does this conversion?

Nope, just how Fetch works - it’ll create a request with defaults and your URL if you only pass a URL

man, coming from object oriented background that is weird. Thanks for letting me know, would never have guessed!

It basically passes your input to the Request constructor

If that’s a request object or a URL, the Request constructor accepts both

Yeah, those links all make sense but I guess I just have to think of it as a black box where it happens by "magic" as opposed to being able to trace the steps like I am used to most of the time.

You could - if you were willing to read through :^) Line 1814 would be a starting point for fetch

Right but I'm talking about tracing through signatures and interfaces and inheritance, not having to understand the implementation. Perhaps it's just that the VS Code typescript interface is inadequate for the purpose or I don't fully understand how typescript implements interfaces. Because something invisible is happening here that would surely be visible in C# or Java

Note - I do appreciate your help, and I don't need to fully understand this in order to just accept that it works the way it does

This is all you'd really get from TypeScript, showing the union of types that'd be accepted

Ah, okay, so I get this which indicates the "Fetcher" is involved somehow:

Ahh, I get it now