Sounds very cool, but first thing that hit my head: Sounds like a perfect tool to DDoS someone?
Cloudflare Workers: Run JavaScript Service Workers at the Edge
81–90 of 134 posts
Re: Cloudflare Workers: Run JavaScript Service Workers at the Edge
#82Sounds very cool, but first thing that hit my head: Sounds like a perfect tool to DDoS someone?
We've thought of that, and it won't be. :)
Re: Cloudflare Workers: Run JavaScript Service Workers at the Edge
#83Hey all! This is my project at Cloudflare. (You may remember me as the tech lead of Sandstorm.io and Cap'n Proto.) Happy to answer questions!
Pretty awesome stuff, will echo that this is one of the cleanest feature pages I've seen. I'd love to hear more about your evaluation of Lua. LuaJIT is so blazingly fast(and small!) that I'm sure it'd be some pretty significant compute savings. What sandbox solutions did you look into? Separate lua states, just overriding ENV/setfenv() or something completely different?
We love Lua and LuaJIT -- we use them extensively here.
But for running third-party code, we need to everything in our power to reduce the risk of a compromise.
Every sandbox (including V8) has bugs, and security is about risk management. With scrutiny, the low-hanging fruit is found and the risk of further bugs steadily decreases. At the end of the day, no Lua sandboxing mechanism has had anywhere near the scrutiny of V8. It's a totally unfair chicken-and-egg problem: to get scrutiny you need usage, but to get usage you need scrutiny. But, it is what it is. :/
Re: Cloudflare Workers: Run JavaScript Service Workers at the Edge
#84This is probably the best annoucement of a new feature I have ever read. It makes an analogy to an existing technology. It provides a clear description of the new feature. It provides clear examples of how to use the new feature with a link to a sandbox so you can run and modify the examples. And it explains the thought process behind the implementation. In additon, I didn't notice a single typo, spelling or grammar…
> I didn't notice a single typo
JavaScript is spelled incorrect all over the place.
Awesome feature and post!
Re: Cloudflare Workers: Run JavaScript Service Workers at the Edge
#85Great product announcement post! I especially liked the Q&A section's reasons for not choosing alternatives.
Is the lack of maturity also the reason for not choosing something like vm2 for NodeJS https://github.com/patriksimek/vm2
Re: Cloudflare Workers: Run JavaScript Service Workers at the Edge
#86This is probably the best annoucement of a new feature I have ever read. It makes an analogy to an existing technology. It provides a clear description of the new feature. It provides clear examples of how to use the new feature with a link to a sandbox so you can run and modify the examples. And it explains the thought process behind the implementation. In additon, I didn't notice a single typo, spelling or grammar…
> I didn't notice a single typo JavaScript is spelled incorrect all over the place. Awesome feature and post!
You're right. Fixed.
(I habitually type it "Javascript" but it is indeed supposed to be "JavaScript".)
Re: Cloudflare Workers: Run JavaScript Service Workers at the Edge
#87Earlier quoted context omitted.
Pretty awesome stuff, will echo that this is one of the cleanest feature pages I've seen. I'd love to hear more about your evaluation of Lua. LuaJIT is so blazingly fast(and small!) that I'm sure it'd be some pretty significant compute savings. What sandbox solutions did you look into? Separate lua states, just overriding ENV/setfenv() or something completely different?
We love Lua and LuaJIT -- we use them extensively here. But for running third-party code, we need to everything in our power to reduce the risk of a compromise. Every sandbox (including V8) has bugs, and security is about risk management. With scrutiny, the low-hanging fruit is found and the risk of further bugs steadily decreases. At the end of the day, no Lua sandboxing mechanism has had anywhere near the scrutiny…
Cool, appreciate the candid response.
I think there's definitely a compelling reason to use JS both from a developer comfort perspective and the fact that it's a pretty battle-tested path.
It sounds like anything short of a full-blown container(with all the overhead that brings) wouldn't be sufficient to cover the security concerns. I'd love to see Lua battle-harded a bit more in that area so was just curious if you had any new learnings.
Re: Cloudflare Workers: Run JavaScript Service Workers at the Edge
#88Great product announcement post! I especially liked the Q&A section's reasons for not choosing alternatives. Is the lack of maturity also the reason for not choosing something like vm2 for NodeJS https://github.com/patriksimek/vm2
I actually didn't know about that one.
Looking briefly, it looks like it's based on creating separate contexts, but not separate isolates. Contexts within the same isolate can be reasonably secure (it's how Chrome sandboxes iframes from their parent frames, after all), but they still share a single heap and must run on the same thread. Isolates can run on separate threads. We prefer to give each script its own isolate, so that one script using a lot of CPU does not block other scripts. We also want to be able to kill a script that does, say, "while(true) {}".
So yeah, it looks like a neat library but it probably wouldn't suit our needs.
Re: Cloudflare Workers: Run JavaScript Service Workers at the Edge
#89Earlier quoted context omitted.
The blog post mentions WebAssembly support in V8, but I can't get it to work in the playground. Coming later?
Yes, we intentionally disabled it for now because the WebAssembly API allows dynamic code loading at runtime. We want all code deployed on Cloudflare to go through our standard deployment process so that we have copies of all of it e.g. for forensic purposes. Also, when we integrate with Cloudflare Apps, that code needs to be moderated. What we'll do at some point is allow you to provide a WASM blob along-side your s…
Makes sense.
Re: Cloudflare Workers: Run JavaScript Service Workers at the Edge
#90Sounds like this could be a pretty trivial way to load balance React prerendering. As long as the react code fetches all data in 1 call it should be at least as efficient as doing it all in Nodejs on your server.