I guess that's true as long as my rate limiting only cares about a window of 10 seconds or less

*30, DOs stick around for 30 seconds after a request

good to know, I think the docs say a minimum of 10s

"In the absence of failures, in-memory state should not be reset after less than 10 seconds of inactivity."

but I guess that's the pessimistic number

I wonder if it's better to implement a rate limiter as a proxy or just as an api that returns whether a request should be allowed..

I guess a proxy would be more efficient

but probably only very marginally?

@Skye hold on a minute, if I hosted my website in a DO wouldn't everyone's requests block every time I made a fetch to another DO / worker?

or is that input output gate stuff only for storage operations?

which I guess I can turn off with

allowConcurrency

and

allowUnconfirmed

I don't know enough about DO's input output gates to answer that

no worries

You're correct in that if the input gate is closed, no new requests will come in. The input gate is opened whenever you make an external async request, such as fetch another DO/worker - so that should open the input gate and allow other requests to be processed in the meantime.

just trying to get my head around what the deal is if every request needed to increment a value in storage, and making the get and then put atomic

I feel like it just works, but I'd love to understand why

I think I just need to read the blog post 10 more times until it all clicks

and probably do some more reading on how javascript concurrency works 😂

"Any other events will be deferred until such a time as the object is no longer executing JavaScript code and is no longer waiting for any storage operations"

I think this is the bit I was missing!

new events wont be delivered while code is executing, only when the event loop is idle

@Skye another potential issue. say my DO needed to calculate some expensive hashing function when a user logs in, that would block all other requests

where as with a worker the other requests would get handled by another instance?

That sounds correct, yes

so I guess you'd just have to be extra careful to have short execution time, and defer anything that might be cpu intensive to another worker/do

I wouldn't really design all of it in DOs unless you had a specific reason for it

It sounds like a lot of the work you want to do could be done in workers, with just specific parts being a DO

@Skye I guess I just liked the idea that my entry point would be colocated with my other DOs so communicating between them would be faster, and things like a rate limit check could even be stored locally to avoid an extra request for each user request

but yeah, premature optimisation

You can generally make a good start on ratelimiting with just the WAF too