7 ms·

Wow, very cool! I didn't see the string "mobile code" in this press release, but that's essentially what this is, right? Automatically moving objects to be near

by catern 6y ago

Wow, very cool! I didn't see the string "mobile code" in this press release, but that's essentially what this is, right? Automatically moving objects to be near the computation that needs it, is a long-standing dream. It's awesome to see that Cloudflare is giving it a try! Plus, the persistence is clever - I'm guessing that makes the semantics of mobility much easier to deal with. I love the migration to nearby edge nodes, but here's a question to any Cloudflare employees around: Have you given any thought to automatically migrating Durable Objects to end user devices? That has security implications of course, so if you've dismissed the idea previously because the security issues are too hard to surface to the developer, that's reasonable.

kentonv 6y ago
> Have you given any thought to automatically migrating Durable Objects to end user devices? We don't have any current plans, but... I was the co-founder of Sandstorm.io before going to Cloudflare, and Durable Objects are very much inspired by parts of Sandstorm's design. So yeah, I've absolutely thought about it. ;) It would definitely have to be an opt-in thing on the developer's part, due to the security considerations as you mention. But I think the possibilities for solving tricky compliance problems are pretty interesting. Protip: "Compliance" is how you say "privacy" while sounding like a shrewd business person instead of an activist. ;)
- Proven 6y ago
  Amateur tip: you can be very heavily fined for violating compliance laws while providing top-notch privacy.
treis 6y ago
>Automatically moving objects to be near the computation that needs it, is a long-standing dream. It's awesome to see that Cloudflare is giving it a try! I'm not sure I see many real world applications for this. It seems to sit in the unhappy middle ground between local device storage and central storage. Local storage is the best performance because you eliminate network issues but then you have to deal with sync/consistency issues. Central storage & processing eliminates sync/consistency issues but can have poor performance due to network. Worker Durable Objects sits in the middle. You trade consistency complications for performance but instead of eliminating the network you're shaving some tens of miliseconds off the RTT. It's a level of performance improvement that essentially no one will notice. To use their examples: >Shopping cart: An online storefront could track a user's shopping cart in an object. The rest of the storefront could be served as a fully static web site. Cloudflare will automatically host the cart object close to the end user, minimizing latency. >Game server: A multiplayer game could track the state of a match in an object, hosted on the edge close to the players. >IoT coordination: Devices within a family's house could coordinate through an object, avoiding the need to talk to distant servers. >Social feeds: Each user could have a Durable Object that aggregates their subscriptions. >Comment/chat widgets: A web site that is otherwise static content can add a comment widget or even a live chat widget on individual articles. Each article would use a separate Durable Object to coordinate. This way the origin server can focus on static content only. The performance benefits for the cart, social feed, and chat are irrelevant. Nobody cares if it takes 50 ms longer for any of those things. IoT coordination is more promising because you want things to happen instantly. Maybe it's worth it here, but people usually have a device on their local network to coordinate these things. Game server would definitely be an improvement. But these things are more complex than some JS functions and it would be a large effort to make them work with Durable Objects.
- eastdakota 6y ago
  Regulatory compliance is the killer feature.
  - treis 6y ago
    Maybe, but not as they are. If I understand it correctly there's no limits by geography. If the Durable Object is created in country A when a worker from Country B accesses it then that data will be replicated to the worker in Country B.
    - kentonv 6y ago
      No, that's not correct. The worker in country B will end up sending a message to the Durable Object which will still be located in Country A. An object only exists in one place at a time. We are working on automatic migration, where if we noticed the object was more-frequently accessed in country B than in country A, then it gets moved to country B. But, that's a performance optimization, and it will be straightforward to implement policies on top of that to restrict certain objects to migrate only within certain political regions.
- catern 6y ago
  >It seems to sit in the unhappy middle ground between local device storage and central storage. No, it's strictly better than both. You get the performance of local storage and the ease of programming of central storage. Pretty much everyone chooses central storage at the moment, so the advantage of mobile objects manifests as performance. I don't know about you, but I would find it a much nicer experience if when I clicked "Add Item" in a shopping cart on some website, it happened <5ms regardless of the quality of my network connection, while still being shared between different machines and never encountering consistency issues. The current "wait somewhere from half a second to several seconds for each click" is bad UX, even if users have gotten used to it.
  - deleted 6y ago
    [deleted]

by catern 6y ago

kentonv 6y ago

> Have you given any thought to automatically migrating Durable Objects to end user devices? We don't have any current plans, but... I was the co-founder of Sandstorm.io before going to Cloudflare, and Durable Objects are very much inspired by parts of Sandstorm's design. So yeah, I've absolutely thought about it. ;) It would definitely have to be an opt-in thing on the developer's part, due to the security considerations as you mention. But I think the possibilities for solving tricky compliance problems are pretty interesting. Protip: "Compliance" is how you say "privacy" while sounding like a shrewd business person instead of an activist. ;)

Proven 6y ago
Amateur tip: you can be very heavily fined for violating compliance laws while providing top-notch privacy.

treis 6y ago

>Automatically moving objects to be near the computation that needs it, is a long-standing dream. It's awesome to see that Cloudflare is giving it a try! I'm not sure I see many real world applications for this. It seems to sit in the unhappy middle ground between local device storage and central storage. Local storage is the best performance because you eliminate network issues but then you have to deal with sync/consistency issues. Central storage & processing eliminates sync/consistency issues but can have poor performance due to network. Worker Durable Objects sits in the middle. You trade consistency complications for performance but instead of eliminating the network you're shaving some tens of miliseconds off the RTT. It's a level of performance improvement that essentially no one will notice. To use their examples: >Shopping cart: An online storefront could track a user's shopping cart in an object. The rest of the storefront could be served as a fully static web site. Cloudflare will automatically host the cart object close to the end user, minimizing latency. >Game server: A multiplayer game could track the state of a match in an object, hosted on the edge close to the players. >IoT coordination: Devices within a family's house could coordinate through an object, avoiding the need to talk to distant servers. >Social feeds: Each user could have a Durable Object that aggregates their subscriptions. >Comment/chat widgets: A web site that is otherwise static content can add a comment widget or even a live chat widget on individual articles. Each article would use a separate Durable Object to coordinate. This way the origin server can focus on static content only. The performance benefits for the cart, social feed, and chat are irrelevant. Nobody cares if it takes 50 ms longer for any of those things. IoT coordination is more promising because you want things to happen instantly. Maybe it's worth it here, but people usually have a device on their local network to coordinate these things. Game server would definitely be an improvement. But these things are more complex than some JS functions and it would be a large effort to make them work with Durable Objects.

eastdakota 6y ago
Regulatory compliance is the killer feature.
- treis 6y ago
  Maybe, but not as they are. If I understand it correctly there's no limits by geography. If the Durable Object is created in country A when a worker from Country B accesses it then that data will be replicated to the worker in Country B.
  - kentonv 6y ago
    No, that's not correct. The worker in country B will end up sending a message to the Durable Object which will still be located in Country A. An object only exists in one place at a time. We are working on automatic migration, where if we noticed the object was more-frequently accessed in country B than in country A, then it gets moved to country B. But, that's a performance optimization, and it will be straightforward to implement policies on top of that to restrict certain objects to migrate only within certain political regions.
catern 6y ago
>It seems to sit in the unhappy middle ground between local device storage and central storage. No, it's strictly better than both. You get the performance of local storage and the ease of programming of central storage. Pretty much everyone chooses central storage at the moment, so the advantage of mobile objects manifests as performance. I don't know about you, but I would find it a much nicer experience if when I clicked "Add Item" in a shopping cart on some website, it happened <5ms regardless of the quality of my network connection, while still being shared between different machines and never encountering consistency issues. The current "wait somewhere from half a second to several seconds for each click" is bad UX, even if users have gotten used to it.
- deleted 6y ago
  [deleted]