Hey, did you mean that a value in globalThis will be the same if the DO instances are running in the
Hey, did you mean that a value in globalThis will be the same if the DO instances are running in the same isolate?
LExactly. Surprising but true. I used a Set of instance ids for my experiments. It was not unheard of but it was rare-ish for there to be two. I don't think I ever saw three. I stopped monitoring years ago because I stopped pre-loading stuff into instance variables and I now retrieve from storage just what I needed to handle that one Request/Message. It sounds inefficient, but it's not with an embedded database that has a cache... and it's more memory efficient. It's also cost effective because reads are dirt cheap.
HAmazing, thanks for explaining, we just added an id/counter to prod and hopefully it will shed light on our problem haha
LIs the DurableObject base class in a repo somewhere that can look at?
1Poking around
workerd
LThanks. I don't know C++ but this is the "interface" essentially. The "implementation" was in a link on the side of the page you took me to so thanks again. It looks like all it does it set
this.ctxthis.envI found other references to DurableObjectBranded that might also be of use
LI think the implementation is here: https://github.com/cloudflare/workerd/blob/main/src/workerd/api/workers-module.c%2B%2B#L25. It's a c++ file and it does what I said. I'm guessing the other c++ foo is just allocating memory and housekeeping. I think I have what I need. Thanks again for the help.
GitHub
The JavaScript / Wasm runtime that powers Cloudflare Workers - cloudflare/workerd
Jrecent message from over in the d1 channel that might be of interest to folks here eagerly awaiting DO storage read replication...
d1-database
d1-database
Nhow much slower is it to use sql reads directly instead of keeping an in memory
Obviously in memory is going to be effectively instant but it's already a hassle to update data in both sql and in memory.
MapObviously in memory is going to be effectively instant but it's already a hassle to update data in both sql and in memory.
LIf you use SQLite DOs there is already an in-memory cache of your reads, so the difference should be negligible. Using in-memory state could make sense within the context of a single request but otherwise it should be fast enough.
LI switched away from keeping instance variables (with a rare exception) a year or so ago and it was one of my best design decisions. We noticed no bump in cost because reads are so cheap and as you pointed out, you already need to do the writes. We noticed no performance penalty. We didn't know how to measure it but we suspect that cold starts got faster by a few ms, although we now believe that's driven by the size of the SQLite storage.
AHas there been any discussion/consideration around adding some built in lifecycle hooks to Durable Objects? For example, these two would be super helpful:
async onWake() - called automatically after a DO is instantiated
async onEvict() - called automatically right before a DO is evicted
My current pattern is to call onWake() myself, but every time the DO is accessed, and it has a flag internally to check if it's already awake. Works, but annoying ergonomics.
For evict, this is trickier, I currently do not know how to catch this. Having this OOTB would allow us to keep DB connections open between multiple requests while the DO is active and serving. Right now, I have to open and close a pg connection for each request which isn't ideal.
I suppose I could use a setTimeout and close when that expires, and reset the timeon on each new request... but that also feels weird.
How are people solving this pattern?
async onWake() - called automatically after a DO is instantiated
async onEvict() - called automatically right before a DO is evicted
My current pattern is to call onWake() myself, but every time the DO is accessed, and it has a flag internally to check if it's already awake. Works, but annoying ergonomics.
For evict, this is trickier, I currently do not know how to catch this. Having this OOTB would allow us to keep DB connections open between multiple requests while the DO is active and serving. Right now, I have to open and close a pg connection for each request which isn't ideal.
I suppose I could use a setTimeout and close when that expires, and reset the timeon on each new request... but that also feels weird.
How are people solving this pattern?
AThe big problem with that is doing any sort of async work in the constructor, like initializing state with same data from a postgres call
Ain a constructor?
AOh yeah.. hmm even the docs show it: https://developers.cloudflare.com/durable-objects/reference/in-memory-state/
Aok, that's great, missed this before
LBTW, I've been using Durable Objects for about 4 years now and it was just last week when I learned something new about it. 
Ahey since you have so much experience, curious... for DOs that need an identity, for ex, let's say you have a DO per tenant
ctx.DO.getByname(tenantId)since you can't know the state ahead of time, is this really the only way to call methods on it:
or is there some clever way to initialize a worker once, and not have to redo it every time?
JI send the id as metadata on every rpc call since any given worker may or may not be initializing the DO given its a singleton.
LYou can't know it's name without doing something like James suggests or what you suggest with
Most of the time, I only need that because I'm using it as the return address for something like @lumenize/proxy-fetch.
There is also another trick I use essentially every time now. I almost always use WebSockets from a browser. My
.initctx.idget(idFromString(id))get(id)Most of the time, I only need that because I'm using it as the return address for something like @lumenize/proxy-fetch.
There is also another trick I use essentially every time now. I almost always use WebSockets from a browser. My
routeDORequest[/${prefix}]/${doBindingName}/${doInstanceNameOrId}[/path...]doInstanceNameOrIdPersonally, I either do the
init()Keep in mind that just because you can do it, you should not do slow operations in the constructor.
While you do that you literally cannot process anything, so with sufficient traffic you will be overloading your DO potentially.
Ideally the constructor should only do light initialization, reading from its storage if needed, or some other "fast-ish" action. Reading from a remote database could take hundreds of milliseconds potentially, so do it if absolutely necessary but be careful and monitor the latency.
While you do that you literally cannot process anything, so with sufficient traffic you will be overloading your DO potentially.
Ideally the constructor should only do light initialization, reading from its storage if needed, or some other "fast-ish" action. Reading from a remote database could take hundreds of milliseconds potentially, so do it if absolutely necessary but be careful and monitor the latency.
Ndoes that apply to SQL too? I can see if KV is cached but sql?
<Does running durableObject.fetch count as a billable request?
LYes, all storage operations use the underlying SQLite engine when using SQLite DOs, therefore benefit from in-memory cache by the runtime already where applicable.
NThat's good.
Ntoo bad there is no way to set multiple alarms. I want an alarm for additional work after returning. But also an alarm to clean up and delete everything after inactivity.
<thanks for your response
LThere are several solutions for this running around. They all work off the same basic concept. They store your alarm specifications in DO storage. This can be quite complicated with recurring alarms specified as well as multiple single alarms in the future. The key is that they make sure the next alarm, according to that stored specification, is the one that the single native alarm is setup for. Smart implementations make sure that if you somehow missed an alarm, it'll get caught and executed-maybe a little late, but not missed. They also have retry logic.
The
Internally, we used the PartyKit one for the 5 minutes we were using PartyKit, then we created our own, now we use a fork of Brayden's. I had on my to-do list to release a well-documented stand-alone package that is pluggable based upon Brayden's implementation. I'll move that to the top of the list for Lumenize and you should have something in a day or so.
The
agents@cloudflare/actorsInternally, we used the PartyKit one for the 5 minutes we were using PartyKit, then we created our own, now we use a fork of Brayden's. I had on my to-do list to release a well-documented stand-alone package that is pluggable based upon Brayden's implementation. I'll move that to the top of the list for Lumenize and you should have something in a day or so.
LAs a thought... based upon your use of "additional work after returning", what are you "returning" from? The reason I ask, that there is
@lumenize/proxy-fetchproxyFetch()Cost-effective external API calls from Durable Objects using Cloudflare Queues
LActually, I just looked at our Alarms port and it looks like the only thing we did was add a Lumenize NADIS (not a DI system) wrapper around it. So, instead of rushing that to market, I'm now working on docs for Brayden's Alarms. I should have that out later today.
AI think the Cloudflare Agent class has that kind of Alarm system
PLarry you deserve a wage from CF ! 
PThanks for your precious involvement, I read and take great interest in your work
LThat makes it all worth it.
LIt does. I included a mention of it in my reply but switching to Agents is a big commitment and I don't trust it since they let a security-relevant bug go unfixed for months
AYeah, I pulled the individual methods out instead of using the whole thing
LThere is Brayden's elegant Alarm class but it's not documented, and by default requires your DO extend the Actor base class unless you duplicate what that base class does manually.You actually don't need the Actor base class. I am a fan of toolkits personally, so we tried
actorsctx.storageSee example in https://github.com/cloudflare/actors/blob/e910e86ac1567fe58e389d1938afbdf1e53750ff/examples/durable-objects/src/index.ts#L21
Same goes for the SQL Schema migrations, you can use them without the Actor base class, and retry utilities too.
LAnd yes, we need to document the whole package better. It's coming.
LHere are the docs. This is the one that shows you the same thing that Lambros just did, namely how to do without extending Actor, but it has API usage docs also: https://lumenize.com/docs/actors/alarms/plain-usage
This is the same thing but using the Actor class: https://lumenize.com/docs/actors/alarms/basic-usage
This is the same thing but using the Actor class: https://lumenize.com/docs/actors/alarms/basic-usage
LApologies for the doc-test format. I realize the testing foo sorta gets in the way of the key stuff. It's just the quickest way for me to write docs that I know are correct. I'll come back with more concise ones some time later.
LBTW, this was a fun exercise. I learned more about Actors and how it implements Alarms. I also learned that testing alarms is less than ideal in 's , so I spent the rest of the day adding alarm testing support to @lumenize/testing, which requires no manual triggering of alarms. I switched the docs linked above over to using it so there is about half the boilerplate that there was before.