4 ms·

What were Workers offering until now without basic tcp network io?

yangcheng 3y ago
http requests, js execution and a kv store. Actually very useful. You can run many stuffs there from simple webhooks to full CMS
mindwok 3y ago
I haven't used Workers, but from the article it seems that they were limited to the standard APIs available across browsers and JS runtimes like Express and Deno, so you could use the fetch API or AJAX for things like HTTP, but there was no standard for raw TCP sockets they could use.
re-thc 3y ago
Tcp is a last resort rather than an important feature. Most tcp connection are built stateful. They expect long running rather than short-style connections like http. It'd be very expensive running serverless tcp connections e.g. to a database.
ZiiS 3y ago
You could do http just not other TCP protocols.
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.

http requests, js execution and a kv store. Actually very useful. You can run many stuffs there from simple webhooks to full CMS

mindwok 3y ago

I haven't used Workers, but from the article it seems that they were limited to the standard APIs available across browsers and JS runtimes like Express and Deno, so you could use the fetch API or AJAX for things like HTTP, but there was no standard for raw TCP sockets they could use.

re-thc 3y ago

Tcp is a last resort rather than an important feature. Most tcp connection are built stateful. They expect long running rather than short-style connections like http. It'd be very expensive running serverless tcp connections e.g. to a database.

ZiiS 3y ago

You could do http just not other TCP protocols.

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.