[catern]

>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.

[treis]

>You get the performance of local storage

Durable workers are still a network call over the internet. That is orders of magnitudes slower than using local storage in the browser.

>when I clicked "Add Item" in a shopping cart on some website, it happened <5ms

You're not going to get that level of performance. All edge storage does is saves you the time it takes a packet to go from the edge to the server. For example, I'm in Atlanta and the Hacker news server is in San Diego. This is my traceroute:

1 LEDE.lan (192.168.1.1) 12.652 ms 12.596 ms 12.561 ms

2 96.120.5.9 (96.120.5.9) 32.606 ms 32.604 ms 32.581 ms

3 68.85.68.85 (68.85.68.85) 34.831 ms 34.821 ms 34.792 ms

4 96.108.116.41 (96.108.116.41) 34.762 ms 34.730 ms 34.706 ms

5 ae-9.edge4.Atlanta2.Level3.net (4.68.38.113) 39.613 ms 64.603 ms 57.149 ms

6 ae-0-11.bar1.SanDiego1.Level3.net (4.69.146.65) 89.310 ms 66.298 ms 76.021 ms

7 M5-HOSTING.bar1.SanDiego1.Level3.net (4.16.110.170) 75.982 ms 69.094 ms 79.199 ms

The last hop in Atlanta before hitting the backbone has a round trip time of ~35ms and the first in San Diego is ~75ms. So everything else equal, if HN was served from a edge location I'd save 40ms on a page load. Ultimately 40 ms doesn't matter because it's not something that the end user can perceive.

[kentonv]

> Durable workers are still a network call over the internet.

Getting the request to the object involves traversing the internet. Once there, actually talking to storage is extremely fast compared to classical monolithic databases. The key is that application code gets to run directly at the storage location.

Most applications need to do multiple round trips to storage to serve any particular request, which is where the costs add up.

> Ultimately 40 ms doesn't matter because it's not something that the end user can perceive.

In ~2005 when I started at Google, I learned that they had done a study that found that every millisecond of latency shaved off the time it took to serve search results would add $1M in annual revenue.

Users may not perceive 40ms in isolation, but they do perceive a web site "feeling" slower if every request takes 40ms longer.