https://discord.cloudflare.com logo
Join Discord
Powered by
# durable-objects
  • h

    HardAtWork

    12/15/2022, 10:25 PM
    Unless an employee snooped my domain, found the ping URL(on the staging domain), and hit it while I was setting it up
  • h

    HardAtWork

    12/15/2022, 10:26 PM
    Seems like an odd coincidence
  • b

    brett

    12/15/2022, 10:28 PM
    Oh, health checks being a CF feature? Yeah that's definitely possible
  • b

    brett

    12/16/2022, 4:31 PM
    locationHint
    is ready if folks want to try it out https://developers.cloudflare.com/workers/runtime-apis/durable-objects/#providing-a-location-hint
  • a

    albert

    12/16/2022, 5:39 PM
    I like this option best. If you do
    namespace.jurisdiction("eu").idFromName("foo")
    , then you're basically just creating a "sub-namespace". It's more clear to have a completely separate namespace for a jurisdiction.
  • a

    albert

    12/16/2022, 5:48 PM
    I think having multiple objects in a namespace with a specific name will always be somewhat confusing, no matter how you try to separate jurisdictions with the syntax.
  • u

    Unsmart | Tech debt

    12/16/2022, 5:50 PM
    I still really do think a name should be unique even across jurisdiction and seeing as that really isnt possible it should be forced on the user to do the name -> id matching instead 🤷
  • a

    albert

    12/16/2022, 5:50 PM
    The definition of a namespace is literally that the identifiers are unique. > A namespace ensures that all of a given set of objects have unique names so that they can be easily identified.
  • u

    Unsmart | Tech debt

    12/16/2022, 5:54 PM
    I would also say forcing the jurisdiction option to the namespace instead would be good but I assume at this point thats probably not an option given its already possible to set jurisdiction on an object level with newUniqueId
  • b

    brett

    12/16/2022, 6:21 PM
    That's one reason. I also think having to make a namespace per Jurisdiction is a weird burden, and forces devs to split up things like metrics and such in a way they may not desire (they could always do it voluntarily if they did)
  • b

    brett

    12/16/2022, 6:21 PM
    Like in the future when we have 50 Jurisdictions, a nice power of DO (I think) is 1 class with 1 namespace can be used for everyone
  • b

    brett

    12/16/2022, 6:25 PM
    I do like to think of
    NS.jurisdiction("foo")
    as a "subnamespace" as noted above. I think that helps make it clear that objects are different. And we should probably update the documentation to say that IDs are unique within a namespace
  • b

    brett

    12/16/2022, 6:27 PM
    Oh sorry, I thought that was from CF docs, that's the dictionary I guess? 🙂 Either way, DOs operate on IDs and not names
  • u

    Unsmart | Tech debt

    12/16/2022, 6:31 PM
    I dont think any way you format will stop people from thinking the idFromName("name") should be unique even if its
    NS.jurisdiction("foo").idFromName("name")
  • b

    brett

    12/16/2022, 6:31 PM
    I wonder how they would think "name" in both "eu" and "us" would work
  • a

    albert

    12/16/2022, 7:39 PM
    What is the reason that names can't be unique across jurisdictions? I thought metadata was globally distributed, even for EU-only objects?
  • c

    ckoeninger

    12/16/2022, 7:53 PM
    Why did you have that impression?
  • b

    brett

    12/16/2022, 7:55 PM
    Additionally, DOs are globally unique, so what would it mean to be talking to "brett" in "us" and "brett" in "eu" at the same time? Where would that object live when you connect to it with WebSockets? Where would its stored data live?
  • a

    albert

    12/16/2022, 8:08 PM
    Well, I think the name "brett" should always map to the same ID, no matter what jurisdiction is specified. The jurisdiction should be set the first time a DO is instantiated from the name "brett". If a different jurisdiction (or no jurisdiction) is specified next time
    idFromName("brett")
    is called, there should either be an error or the object should be created in the jurisdiction that was specified the first time
    idFromName("brett")
    was called.
  • a

    albert

    12/16/2022, 8:09 PM
    There should be no difference between "brett" in EU and "brett" in US, since "brett" should only be able to exist in one jurisdiction. "brett" should be unique within the namespace.
  • b

    brett

    12/16/2022, 8:10 PM
    FWIW, metadata about object isn't globally distributed, EU objects are only in EU colos. So the act of checking if "brett" is in any Jursidiction isn't that easy (especially once we have a lot of them)
  • b

    brett

    12/16/2022, 8:10 PM
    I could see a world where we did that and threw an error (but we don't really live in that world, I think). I think silently loading "brett" from a different Jurisdiction would be very bad, though.
  • a

    albert

    12/16/2022, 8:11 PM
    I agree an error would be better. Is there a reason metadata for EU objects is not distributed to non-EU colos? The name is hashed anyway, right?
  • b

    brett

    12/16/2022, 8:11 PM
    My gut feeling is if people are afraid of this they can pretty trivially use
    ${jurisdiction}/${originalName}
    for their object names
  • b

    brett

    12/16/2022, 8:12 PM
    Yeah, the name isn't available at that point, just the ID. This was done at the interpretation of legal, IIRC.
  • b

    brett

    12/16/2022, 8:13 PM
    To be clear, that's true for all objects, not just Jurisdictions
  • b

    brett

    12/16/2022, 8:13 PM
    Generally speaking we don't distribute metadata around the world
  • b

    brett

    12/16/2022, 8:13 PM
    It's pretty core to the design
  • a

    albert

    12/16/2022, 8:16 PM
    You don't distribute the information that " exists in " around the world?
  • b

    brett

    12/16/2022, 8:17 PM
    Nope
1...459460461...567Latest