4 ms·
I thought the reason why Cloudflare Workers were great is that they utilize the many CDN points that Cloudflare owns. Or you can use Blueboat with say Fastly an
by nikivi 5y ago
I thought the reason why Cloudflare Workers were great is that they utilize the many CDN points that Cloudflare owns. Or you can use Blueboat with say Fastly and achieve nearly the same thing?
- zild3d 5y agoSame, the cloudflare workers tagline is "Deploy serverless code instantly across the globe to give it exceptional performance, reliability, and scale." Maybe I missed something in the blueboat readme, but don't see how this deploys across the globe and scales automatically How about 0ms cold starts? Is this actually open source cloudflare workers or just open source serverless functions? https://workers.cloudflare.com/ https://workers.cloudflare.com/
- tentacleuno 5y agoSee OP's top comment[0], specifically this part: > Blueboat is not yet optimized for global-scale operation but it is definitely the goal. Things not implemented include: custom TLS termination (which enables 0ms cold start) [0]: https://news.ycombinator.com/item?id=29325570 https://news.ycombinator.com/item?id=29325570
- shoelessone 5y agoSame (blue) boat here. To be honest, how Cloudflare Workers work is a bit of a mystery to me as I've only done some very basic prototyping with the service (and not really focusing on the "edge" aspect of them), but it seems like the important "stuff" that makes them what they are is how they are deployed. I am REALLY going to show my ignorance here, but is there some chance that the idea is these "workers" are intended to be deployed in the users browser for example, as actual service workers or something? i.e. is this more of a framework for creating service workers vs running in the "backend"?
- emj 5y agoCloudflare workers are executed on servers and quickly thrown away, they use APIs that make this clear as well, it has nothing to do with service workers. Could you expand a bit on you question?
- ushakov 5y agoi think cloudflare worker is basically like a browser tab the only difference is that your browser is cloudflare and globally-distributed
- beepbooptheory 5y agoCloudflare workers != js workers. Kinda seems like that's what you are talking about at the end. In my understanding, Cloudflare workers, and "edge" stuff generally, are more like ephemeral server processes that can happen per request, which are backed by some kind of extensive infrastructure that cloudflare, aws, et al can provide. Its not a server, but the promise a server will be there if someone hits that endpoint. Anything client side is not changed.
- ethbr0 5y agoServerless is compute execution, pure and OS-less. The genius of Cloudflare Workers is that it couples the one place Cloudflare beats Amazon (their global ubiquity and edge deployment) into a product feature that a customer cares about. The real genius of AWS at all wasn't "We can sell a thing people will buy" but rather "We can sell excess capacity on a thing we have to have, in order to offer {other, core product}." And Cloudflare has to have network connectivity and minimal latency.
- mnutt 5y agoCloudflare Workers have their own additional compelling value prop in operating on the edge. But I think something like this could offer a lot of value for a different use case: In building complex SaaS apps, there's usually a constant flow of customer requests for custom features. Scripting, if managed very carefully [0], can provide an outlet for that and also allow people to glue together different features. AWS pushes people towards Lambda for customizing/gluing different AWS services. A product could use AWS Lambda for its own scripting/glue, but that may end up being a little bit too free-form and depending on the use case Lambda cold start times may be unacceptable. So something like Blueboat could eventually be useful for running untrusted code to power customization of SaaS apps. This is especially the case if your service isn't marketed toward developers who can easily run their own Lambdas. [0] Opening your app to scripting automatically exposes a huge API surface area which you'll likely have to support for a long time.