Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reality Check for Cloudflare Wasm Workers and Rust

nickb.dev

Post reply on HN
Print view View original

21–30 of 59 posts

Re: Reality Check for Cloudflare Wasm Workers and Rust

#21

Post by csomar »

eloff wrote: post #16
csomar wrote: post #7

Earlier quoted context omitted.

> I think the one-sentence version of this is that Workers are meant for small, undemanding tasks (for example, they have tight memory limits and don’t have great performance) That could be most web apps functionalities. Things like registration, authorization/authentication, sending emails, store/retrieve data, etc... > so using them to do “serious number crunching” at the edge, which is the advertised use case, see…

Workers does have a Cron like functionality. My memory is fuzzy but it's been around for a while. https://developers.cloudflare.com/workers/platform/cron-trig...

Assuming you pull results every 1 second, that's 86.4k requests a day for each potential user you have. Another solution, is it have a single CRON worker that watches for all notifications, kinda a basic implementation for a Push API.

Re: Reality Check for Cloudflare Wasm Workers and Rust

#22

Post by csomar »

wrkronmiller wrote: post #8
csomar wrote: post #7

Earlier quoted context omitted.

> I think the one-sentence version of this is that Workers are meant for small, undemanding tasks (for example, they have tight memory limits and don’t have great performance) That could be most web apps functionalities. Things like registration, authorization/authentication, sending emails, store/retrieve data, etc... > so using them to do “serious number crunching” at the edge, which is the advertised use case, see…

Given HTTP pipelining and fetch() promise semantics, I'm not sure there's a practical benefit to pushing results instead of "blocking" the original request.

If you want to run something in the background whether the user page is still active or not. Once the computation is complete, it pushes a notification to the user or trigger other workers.

Re: Reality Check for Cloudflare Wasm Workers and Rust

#23

Post by comagoosie »

brundolf wrote: post #2

> I guess I’ll stick with my error prone Javascript Workers or, more likely, spend an afternoon migrating to a minimal Typescript setup. If the OP wants a zero-config typescript experience (assuming Deno isn't available on Cloudflare workers), I can't recommend esbuild enough

I think this is an excellent suggestion (I'm OP / author), and one one can add just a dash to this for typechecking. Minimal setups are appreciated, especially when one has many small projects.

Re: Reality Check for Cloudflare Wasm Workers and Rust

#24

Post by brundolf »

comagoosie wrote: post #23
brundolf wrote: post #2

> I guess I’ll stick with my error prone Javascript Workers or, more likely, spend an afternoon migrating to a minimal Typescript setup. If the OP wants a zero-config typescript experience (assuming Deno isn't available on Cloudflare workers), I can't recommend esbuild enough

I think this is an excellent suggestion (I'm OP / author), and one one can add just a dash to this for typechecking. Minimal setups are appreciated, especially when one has many small projects.

Glad I could help! Esbuild won't do the actual type-checking for you, but your editor will (hopefully also without configuration)

I'll put it this way: I've spent enough time with Webpack and Babel and TSC at this point that I can troubleshoot most issues without too much difficulty. But despite that I reach for esbuild every time I possibly can, because I just don't want to mess with all that stuff if I don't have to.

Re: Reality Check for Cloudflare Wasm Workers and Rust

#25

Post by kentonv »

up6w6 wrote: post #9

iirc the compilation time of wasm in Cloudflare Workers is very problematic[1] and right now it contradicts their idea of running low latency fast scripts, does anyone know if anything has changed ? https://community.cloudflare.com/t/fixed-cloudflare-workers-...

Yes, it has changed, which is why the thread you linked has "[FIXED]" in the title. Details can be found later on in the thread.

Re: Reality Check for Cloudflare Wasm Workers and Rust

#26

Post by eloff »

csomar wrote: post #21
eloff wrote: post #16

Earlier quoted context omitted.

Workers does have a Cron like functionality. My memory is fuzzy but it's been around for a while. https://developers.cloudflare.com/workers/platform/cron-trig...

Assuming you pull results every 1 second, that's 86.4k requests a day for each potential user you have. Another solution, is it have a single CRON worker that watches for all notifications, kinda a basic implementation for a Push API.

A request per second per user is just bad architecture. You will need something like you're saying to batch processing in some way.

Re: Reality Check for Cloudflare Wasm Workers and Rust

#27

Post by kentonv »

dgreensp wrote: post #4

I think the one-sentence version of this is that Workers are meant for small, undemanding tasks (for example, they have tight memory limits and don’t have great performance), so using them to do “serious number crunching” at the edge, which is the advertised use case, seems questionable. I think the blurb about the downsides of Wasm is just too generic, it’s a sort of “why Wasm isn’t preferable to JS in all cases” fo…

> I think the one-sentence version of this is that Workers are meant for small, undemanding tasks

Not at all! We're building a platform on which you can build your entire app. What you say may have been the case four years ago when Workers launched, but since then we've added Durable Objects, Cron triggers, much longer time limits, etc. We very much believe Workers can be a stand-alone alternative to other cloud providers.

> for example, they have tight memory limits and don’t have great performance

This isn't true.

"Performance" is a vague term, you need to clarify the use case and what you're measuring. But, I can't think of what you could mean by "don't have great performance", that seems to imply that they execute code slower or something, which just isn't true at all. In many cases, Workers perform much better than you could achieve with any other platform, due to the ability to spread work and data across the network and move it close to where it's needed.

The "memory limit" on a single worker instance is 128MB, but Cloudflare runs many instances of the worker around the world, so across the network you're really getting many gigabytes of memory. By building a distributed system based on Durable Objects, you can harness the memory of many instances to use on a single task. Workers definitely biases towards distributing load across the network rather than running a single fat instance of your server, but that just means Workers makes it easy to build apps that scale to much higher.

What this article is highlighting is that Wasm is still an immature technology. That is, unfortunately, just a fact. There's still work to be done, and progress is being made, but it's still early. The code footprint issue (because every app must bring along its own language runtime) is the biggest blocker. We hope to see that solved with dynamic linking.

But, Workers isn't primarily based on Wasm. The vast majority of Workers are written in JavaScript, where these issues don't exist. Workers runs JavaScript just as fast as any Node.js server, and runs it closer to the client resulting in better latency.

Re: Reality Check for Cloudflare Wasm Workers and Rust

#28

Post by kentonv »

csomar wrote: post #7
dgreensp wrote: post #4

I think the one-sentence version of this is that Workers are meant for small, undemanding tasks (for example, they have tight memory limits and don’t have great performance), so using them to do “serious number crunching” at the edge, which is the advertised use case, seems questionable. I think the blurb about the downsides of Wasm is just too generic, it’s a sort of “why Wasm isn’t preferable to JS in all cases” fo…

> I think the one-sentence version of this is that Workers are meant for small, undemanding tasks (for example, they have tight memory limits and don’t have great performance) That could be most web apps functionalities. Things like registration, authorization/authentication, sending emails, store/retrieve data, etc... > so using them to do “serious number crunching” at the edge, which is the advertised use case, see…

> Cloudflare workers don't run in the background. They block the HTTP request. For serious computation, Cloudflare should offer background workers that can run for extended periods of time.

You can use `event.waitUntil()` to schedule a task that runs after the HTTP response has completed, and you can use cron triggers to schedule background work in the absence of any HTTP request at all. You can even build a reliable async queuing system on top of cron triggers and Durable Objects, though at the moment it's a bit DIY -- we're working on improving that.

Re: Reality Check for Cloudflare Wasm Workers and Rust

#29

Post by mst »

brundolf wrote: post #12
wibagusto wrote: post #10

Earlier quoted context omitted.

WASM tasks shouldn’t need a full standard library. If you statically compile against any library it should only keep the pieces used.

That's fair, but still, you'll be pulling in a lot of really fundamental stuff that JavaScript gets for free. String manipulation, fundamental data structures, iterators, HTTP, JSON (de)serialization, etc.

One of the examples he mentioned was 200Kb.

That's still a lot more than "a single file of javascript", certainly, but it's not that bad.

Trade-offs all the way down, as ever.

Re: Reality Check for Cloudflare Wasm Workers and Rust

#30

Post by azakai »

kentonv wrote: post #27
dgreensp wrote: post #4

I think the one-sentence version of this is that Workers are meant for small, undemanding tasks (for example, they have tight memory limits and don’t have great performance), so using them to do “serious number crunching” at the edge, which is the advertised use case, seems questionable. I think the blurb about the downsides of Wasm is just too generic, it’s a sort of “why Wasm isn’t preferable to JS in all cases” fo…

> I think the one-sentence version of this is that Workers are meant for small, undemanding tasks Not at all! We're building a platform on which you can build your entire app. What you say may have been the case four years ago when Workers launched, but since then we've added Durable Objects, Cron triggers, much longer time limits, etc. We very much believe Workers can be a stand-alone alternative to other cloud prov…

Small note on this:

> What this article is highlighting is that Wasm is still an immature technology.

I assume you meant on the server, where wasm is fairly new, that's true. On the browser, wasm is a mature and stable part of the Web platform.

Otherwise very good points!

Post reply on HN