which means it's going to be more expensive than just using cloudflare DO

Yes, in a way, but what I am saying is, you can consider this an option if you're wanting simpler implementation and not worry about dynamic pricing. But it is not just the sheer costs you should worry about. Sometimes other features/benefits may or may not outweigh the costs.

alright

Planet scale can give you MySQL-like benefits, and of course, you can read the data from somewhere else as well. But with DO you have to use another worker to read and write to the DO. And if you need to scale to more than 100 requests per second, DO may cause some issues, because DOs are single-threaded. Although very fast, it has a limit, because of the fact that it's single-threaded. So, for customers doing more than 1000 requests per second, (if you have such customers) then it would not be able to handle.

We have to look at Cloudflare D1 pricing. It is a good thing, but if costs are comparative, then it would be a very good contender.

I was looking into that. D1 isn't production ready and prices for it aren't yet released sadly.

Yes, however, it will be shortly. But till then I guess you can just make do with Durable Objects.

Yep

Let me know how your implementation goes, I am trying to build a similar counter and block thing.

@Unsmart | Tech debt for when you get online: I'm trying to use the following durable object for my use-case:

javascript
export class Counter {
    constructor(controller, env) {
        this.storage = controller.storage;
    }

    async initialize() {
        let stored = await this.storage.get("value");
        this.value = stored || 0;
    }

    async fetch() {
        if (!this.initializePromise) {
            this.initializePromise = this.initialize();
        }
        await this.initializePromise;

        ++this.value;
        await this.storage.put("value", this.value);

        return new Response(this.value);
    }
}

However, it isn't working as excepted. When I restart the dev server or wait a bit, the value resets back to 0. How do I fix this behavior?

Nevermind! Solved my issue from the docs: > wrangler dev has read access to Durable Object storage, but writes will be kept in memory and will not affect persistent data. However, if you specify the script_name explicitly in the Durable Object binding, then writes will affect persistent data. Wrangler 2 will emit a warning in that case.

@Unsmart | Tech debt is there any alternative to this madness?

Don't delete and remake constantly?

How else am I supposed to test them?

migrations seem like a horrible solution for this imho

there's definitely better ways to manage this

Are there any suggestions for running end-user code in durable objects? I’m thinking of having a wrapper class and then importing a class they made with a set of expected methods. Will have to do a deployment for each end user. Security might also be a concern

I specifically want to run in the DO to have low latency to the data

Testing locally works great

Doesn't work if you want to maintain storage

--persist is a thing? Not sure what you mean

if you delete & create new storage is cleared anyways

That's mentioned absolutely nowhere in the docs except for the wrangler commands section.

they should definitely consider mentioning it somewhere useful to avoid people like me creating tons of spam in their config

sure I guess, but wrangler is the tool of choice for development, and they mention using

wrangler dev

for development, so idk

i think that’s what this is for: https://developers.cloudflare.com/cloudflare-for-platforms/workers-for-platforms/learning/how-workers-for-platforms-works/

I don’t believe you can make a durable object, but you can bind one

hmmm, i see. depending on what you need, i wonder if you could use quickjs via wasm.

I don’t think wasm is supported for durable objects?