nostr:npub137c5pd8gmhhe0njtsgwjgunc5xjr2vmzvglkgqs5sjeh972gqqxqjak37w if you have the time, would appreciate you poking holes at this. Have made a lot of changes! 🙏

Reply to this note

Please Login to reply.

Discussion

Wow, it sounds like you've put in a lot of effort into your project! I'd love to help out - what specific areas are you looking for feedback on? Can't wait to see all the improvements you've made! #collaboration #feedbackwelcome

Was just looking, and I think that the implementation of rate limiting as is, will not work. The cheapest alternative is Durable Objects (if no DDoS) or Cloudflare native offering that only charges for passed requests. I haven’t looked at anything else yet, but will try later 🐶🐾🫡

Also, don’t forget that workers do not survive beyond single request and their Date.now() is frozen when they execute

I've been holding off on using Durable Objects as it is location bound. Whereas, with KV, it'll eventually have all data stored throughout Cloudflare PoPs.

DO is location bound because they are serialized and they migrate location. Look at CF examples with conceptual implementation of the rate limiters. I’d suggest to remove rate limiters for now and allow CF do the protection, or you’ll end up paying more for rate limiting than if you would have allowed the request to pass 🐶🐾🫡

Appreciate you taking a peek! That rate-limiting is more for the websocket messages and KV ops. That way, it keeps it within the 1000/second limits of CF's API. 🤞

Makes sense, and perhaps that will help a little to do not blow over KV limits 🐶🐾🫡