with round trip to the worker and back to my client it takes like 40ms in total

and the worker itself usually responds within 20ms for a very simple response, but for SSR and all the other route matching its roughly ~30ms on average

which is leaving me wondering whether I should just check auth on every single call, or if I should still use JWTs or something

I guess id still need to check the sig of the JWT and keep it in the KV

so I might as well just query the users DO every call and check if their token is valid

I’m using the KV for my tokens because the DO is very slow on my city. The round trip is 180ms ;

But I usually write on KV using DO + waituntill(), in this case I don’t need to wait the KV write and still get the advantages of the DO as “Actor” …

Hmm that’s interesting

I might use KV for the auth tokens but I’m not sure

I wouldn’t consider 180 very slow, that’s still like half of what aws lambda can offer

with expiring KV keys, is there a way to get the expiration date of it?

so like, I can tell if its about to expire and refresh it?

Is there a way to access DO without a fetch request? If you just want to do internal stuff, not from the user/client?

Or do you have to create a "fake" request if its not relevant to the actual incoming request

after the initial creation, is there any benefit to caching the id or is using idFromName() pretty much/exactly as fast?

You would call

deleteAll

from within the durable object.

Where are you located, and are you using

idFromName

or

newUniqueId

?

No, the only API currently available is HTTP. I'm not sure what you mean by internal, you can design your own URL Path / HTTP Method routing inside of the DO

Each Cloudflare colo will cache the true location of a named DO the first time it is accessed from that location.

The

list

method will return expiration info, or you could (redundantly) put your own expiration info in metadata and use

getWithMetadata

To be clear,

idFromName()

always returns instantly, it computes the ID without doing any network communications. The delay comes when you access the object. The first time it is accessed, the system has to check if the same ID has already been used anywhere else in the world, which can be slow. The information is then cached in the calling colo, so subsequent requests from the same colo will use the cached information and will be faster. Though eventually the cache may be evicted, of course.

Yup, that makes perfect sense. Out of interest, when you do

DurableObjectNamespace.get(id): DurableObjectStub

, is your implementation something like you fork off a getOrCreateDO() call and then return the stub? Or does that bit get done when you do the first fetch()?

When you do get(id), we send out the network request to find the object. We can immediately return a stub because we use Cap'n Proto under the hood, which implements something called "Promise Pipelining". When you call fetch(), we can send the fetch message even if the initial lookup hasn't completed yet, by sending it as a pipelined request. https://capnproto.org/rpc.html

idFromName ; Brasilia - Brazil

Good to know. You are right that we still need to enable DOs in colos closer to you.

@User Any plans to make the durable to "auto store" properties like the "itty-durable" project? I mean, you can get rid the entire fetch inside of the durable and map the properties/actions calls outside the JS to performance gain. Im not talking about the save the current memory state, only the properties of the durable class (like the itty-durable project). You can also optimize the read operation if the DO is inside of the same datacenter.

But does that delete the durable object itself?

Just the storage

ah

but it effectively removes it