Hacker News Reader

Comment by csomar | Hacker News Reader

> 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, seems questionable.

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. [1]

1: This could be tricked by triggering an async request, but there is no push API to get notify the "App" of the result.

View on HN

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.

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

Thanks. I didn't know about waitUntil, that can unlock some powers.

> we're working on improving that.

I'd assume you are working for Cloudflare. Do you see it going the way of firebase?

I'm the tech lead for Cloudflare Workers. :)

I don't know much about Firebase, to be honest, so I'm not sure how to answer that question. But, our aim is that every type of server compute should be something you can build on Workers. Meanwhile, our design philosophy is that Workers should feel like you're programming one big, globe-spanning computer, rather than lots of individual servers.

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.

Reply on news.ycombinator.com