4 ms·

Static file serving, HTTP requests, eventually-consistent Key-Val store, and a funky sort of way to able to edit/view consistent data from a single location, bu

by jakear 3y ago

Static file serving, HTTP requests, eventually-consistent Key-Val store, and a funky sort of way to able to edit/view consistent data from a single location, but only if you pay minimum $5 month (anyone out there like Durable Objects?).

crabmusket 3y ago
I'm currently building a real-time multiplayer editor on durable objects and I love them. I wish other cloud providers would ruthlessly copy them so I don't have that vendor lock-in feeling.
- jakear 3y ago
  Are you bothered by how they only stay alive for 60s or so before being killed? Or the somewhat difficult to estimate pricing? I eventually just decided for those use cases I'd rather run a dedicated server. Pricing is easier, no lock in, and it doesn't die on me unexpectedly.
  - crabmusket 3y ago
    They usually stay alive while they're receiving requests and die after a period of inactivity - though they can also die unexpectedly for other reasons. This necessitates some more careful design - clients must assume the server can go away at any time and therefore work in a local-first fashion. I was interested in doing that anyway, so it didn't feel like an imposition. I think the core of what I really like about DO's is that it's a single thread with a globally unique and accessible address.
    - jakear 3y ago
      I agree the value proposition is compelling. Another annoyance is how little it gels with the rest of Pages. I'd expect that if I'm developing an application from the ground up in Pages, incorporating the various Cloudflare value-ads should come relatively naturally. Instead I need to have entirely separate projects just for these components.
      - jgrahamc 3y ago
        Then you'll be glad about: https://blog.cloudflare.com/pages-and-workers-are-converging-into-one-experience/ https://blog.cloudflare.com/pages-and-workers-are-converging...
      - crabmusket 3y ago
        Agreed on Pages, though I'm not using that personally. I forgot to mention about pricing. We've taken the approach of estimating a "worst case" time per object and requests/second rate. E.g. we assume a worst case of 30 req/s for the lifetime of the project, based on 3 users simultaneously sending updates at a rate of 10/sec each. And maybe we assume 1-2 hours of cumulative time spent in the editor per object. Multiply that out to get a value of GB-seconds per object, multiply by the respective prices, and add to get the total "expected lifetime cost per thing". (We're not actually using durable objects' built-in storage, so this would indeed be complicated by trying to price that in. We only wanted DOs for coordination.) If it's hard to estimate the total lifetime of a thing, you could estimate against something like how many hours can/will each user spend in your app per month, and come up with a monthly benchmark price. We haven't done that as the objects we deal with have naturally limited lifespans, and our pricing is tied to the number of these objects created anyway.

by jakear 3y ago

crabmusket 3y ago

I'm currently building a real-time multiplayer editor on durable objects and I love them. I wish other cloud providers would ruthlessly copy them so I don't have that vendor lock-in feeling.

jakear 3y ago
Are you bothered by how they only stay alive for 60s or so before being killed? Or the somewhat difficult to estimate pricing? I eventually just decided for those use cases I'd rather run a dedicated server. Pricing is easier, no lock in, and it doesn't die on me unexpectedly.
- crabmusket 3y ago
  They usually stay alive while they're receiving requests and die after a period of inactivity - though they can also die unexpectedly for other reasons. This necessitates some more careful design - clients must assume the server can go away at any time and therefore work in a local-first fashion. I was interested in doing that anyway, so it didn't feel like an imposition. I think the core of what I really like about DO's is that it's a single thread with a globally unique and accessible address.
  - jakear 3y ago
    I agree the value proposition is compelling. Another annoyance is how little it gels with the rest of Pages. I'd expect that if I'm developing an application from the ground up in Pages, incorporating the various Cloudflare value-ads should come relatively naturally. Instead I need to have entirely separate projects just for these components.
    - jgrahamc 3y ago
      Then you'll be glad about: https://blog.cloudflare.com/pages-and-workers-are-converging-into-one-experience/ https://blog.cloudflare.com/pages-and-workers-are-converging...
    - crabmusket 3y ago
      Agreed on Pages, though I'm not using that personally. I forgot to mention about pricing. We've taken the approach of estimating a "worst case" time per object and requests/second rate. E.g. we assume a worst case of 30 req/s for the lifetime of the project, based on 3 users simultaneously sending updates at a rate of 10/sec each. And maybe we assume 1-2 hours of cumulative time spent in the editor per object. Multiply that out to get a value of GB-seconds per object, multiply by the respective prices, and add to get the total "expected lifetime cost per thing". (We're not actually using durable objects' built-in storage, so this would indeed be complicated by trying to price that in. We only wanted DOs for coordination.) If it's hard to estimate the total lifetime of a thing, you could estimate against something like how many hours can/will each user spend in your app per month, and come up with a monthly benchmark price. We haven't done that as the objects we deal with have naturally limited lifespans, and our pricing is tied to the number of these objects created anyway.