Yes - although you notably can't export a DO class when using a Service Worker so I assume you've made the DO with another Worker

Oh can you not 🤔 didn't realise that

Oh I see

In general, we recommend using module syntax, as it is the more modern/efficient standard

Are there any libraries the community has created for managing secondary indexes for DO storage?

Or database libraries that sit on top of DO storage with secondary indexes and querying

Like #992060581832032316 ?

Haha, I was thinking something simpler, JS-only.

simpler is relative. I was looking for a light no-sql solution that made it a littler easier to work with DO storage. I'm thinking about how I would create it for my needs, but I thought I would ask before doing my own thing.

google-cloud-partner-directory@google.com

What's going on?

🤔

At this point the FetchEvent API should be deprecated… more confusing to have it around than it’s worth. It should be put behind a compatibility date, IMO.

There's still a lot of code across docs & templates that need to be updated before that could happen

In blog posts too

I don't agree that it needs to happen first... if wrangler or the runtime just logs a warning that'll help smoke out where outdated docs live.

Does anyone know how input/output gates interact with alarms? Alarms are not ‘inputs’ or ‘outputs’ per se and I wouldn’t want a race condition. I am assuming that they’re implemented as ‘inputs’ but I just wanna double-check with someone who knows.

Hello, I have a question: When is the durable object actually created? From the counter template (https://github.com/cloudflare/durable-objects-template):

javascript
async function handleRequest(request, env) {
  let id = env.COUNTER.idFromName("A");
  let obj = env.COUNTER.get(id);
  let resp = await obj.fetch(request.url);
  let count = await resp.text();

  return new Response("Durable Object 'A' count: " + count);
}

Is it created like when you do env.COUNTER.get(id)? If the object does not exist when we create the stub it is created and instanciated? If yes, then I got another question, if the durable object that was created did not store anything inside of his storage does the object will still exist forever and will I have to pay anything?

The object is created when you first fetch it. Objects that exist(but are shut down) aren’t billed, only their storage is. And if they don’t store anything, they are deleted after a while

Thanks ❤️

I do also have another question: According to documentation:

javascript
// Durable Object storage is automatically cached in-memory, so reading the
// same key every request is fast. (That said, you could also store the
// value in a class member if you prefer.)

But also for pricing:

Read request units    1 million, + $0.20/million

So if I am correct, for every time that I do:

javascript
await this.state.storage.get("value");

I am billed for 1 read request. But actually if the data is cached in-memory during the read, am I still billed this amount? Because otherwise, I could just store it myself in memory every time in order to save money

Yes, you are billed for every read, in-memory or not

Thanks, so if I just store the key like

javascript
this.value = await this.state.storage.get("value");

I wont be billed if I access this.value (if the object is alive)

Yup

Thanks ❤️

Hey Jacob I saw you posted a question about Macrometa a while back. Did you end up finding a solution like you talked about?

Hey, also looking for solutions to put CRDT / y.js on top of serverless storage. I saw your question about it in the Durable Object discord channel. Have you found any solution so far?