https://discord.cloudflare.com logo
Join Discord
Powered by
# durable-objects
  • m
    Can you tap into the “error” event to see if an error is detected, even if it isn’t thrown?
  • m
    (Look for close code 1006)
  • v
    Yea zombie socket, send works but other end is disconnected.
  • v
  • v
    Big thanks, i would not have been able to implement it without this. it works!
  • v
    is there a way to disable strict mode on rollup?
  • v
    it seems the nodejs package i imported has a very old dependency, that violates strictmode
  • v
    and the entire project does not want to compile now
  • e
    Copy code
    output.strict
Type: boolean
CLI: --strict/--no-strict
Default: true

Whether to include the 'use strict' pragma at the top of generated non-ES bundles. Strictly speaking, ES modules are always in strict mode, so you shouldn't disable this without good reason.
  • v
    yea i tried it didnt help
  • v
    im just gonna use the module as a UMD
  • v
    (or atleast try)
  • e
    Yeah, that is what I would have tried next too..
  • d
    Yup, I'd done that, and you're right about it being 1006: 
    {"wasClean":false,"reason":"WebSocket disconnected without sending Close frame.","code":1006,"type":"close"}
  • d
    Hah, now you point me back to that message I can remember reading it (but it wasn't relevant to me then :P). It looks like they know about it, but I still think the demo should be changed... Maybe I'll drop in a PR once I'm 100% happy with my ping/pong fix.
  • t
    Regarding the behind-the-scenes optimization of IDs generated with 
    idFromName
    , is cloudflare essentially "caching" the global position/ID/etc. with KV? I'm considering implementing a KV mapping between my domain specific names/IDs and DO IDs generated using 
    newUniqueId
    , but I imagine this might already be done behind the scenes... is this the case?
  • b
    Yeah, we do cache their location (though not in KV). I'm not sure that doing your own layer in KV would add any benefit over just using 
    idFromName
  • e
    Remember the advantage from 
    newUniqueId
    is only in the initial creation of the DO.. any subsequent invocations will run at very comparable speeds.
  • b
    Kind of 🙂 Each colo caches the true location, so the first request from any given colo may be a little slower (but this wouldn't be very different from getting it from KV) -- and of course the cache item could be evicted, etc.
  • b
    But yeah, from a single given client location you can expect them to be very similar after that first request
  • e
    Ah yeah, you have the first request per colo too. But yeah, that wouldn't be much different than a KV one indeed.
  • b
  • b
    ^ some Durable Object fun
  • j
    ohhh is this the post Erwin mentioned
  • j
    oh that is super cool
  • t
    thanks for the thorough responses yall
  • t
    btw that doom blog post is badass
  • t
    could concurrency ever be an issue for such an application?
  • t
    given that DOs are single-threaded?
  • m
    I'm not sure it'd be a problem until you get 20 or more clients
1...858687...567Latest