Live data from Hacker News

Cloudflare Workers: Run JavaScript Service Workers at the Edge

blog.cloudflare.com

61–70 of 134 posts

Re: Cloudflare Workers: Run JavaScript Service Workers at the Edge

#61
post #2

Hey 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!

Hey Kenton, should've guessed you were behind this. Lovely design, great work. I'd be curious to learn more about the implementation (did you lift the existing SW implementation from blink somehow, or reimplement it)?

Hey Aaron!

I looked a bit at the code in Chrome but determined that it was too attached to Chrome infrastructure that didn't make sense in our use case. Also, there are a lot of parts of Service Workers that don't make any sense outside the browser, so it looked like it would be pretty hairy trying to pull those apart. So, we're building our own implementation (a lot of which is still in-progress, of course).

I actually built a little V8 API binding shim using template and macro metaprogramming that I really like, which allows us to write classes in natural C++ and trivially export them to Javascript. We've been filling in the various non-V8-builtin APIs using this.

We're using libkj's event loop, HTTP library, and other utility code. (KJ is the C++ framework library that is in the process of spinning out of Cap'n Proto. Yeah, I may be suffering NIH, but I think it's worked well.)

Re: Cloudflare Workers: Run JavaScript Service Workers at the Edge

#64
post #60
post #2

Hey 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!

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 script, which will be loaded separately and then exposed to your script probably as a global variable.

Re: Cloudflare Workers: Run JavaScript Service Workers at the Edge

#66
post #14
post #11

Earlier quoted context omitted.

So, more like https://aws.amazon.com/lambda/edge/ ?

That is correct. However, the design is very different. Lambda@Edge is, from what I can tell, based on running a full Node.js process in a process-level sandbox for each customer, whereas we are embedding V8 directly.

What are you embedding v8 into exactly? What happens if I figure out a buffer overflow in v8? What do I break out into? Is it solely process isolation? Is it in a container? A VM?

Re: Cloudflare Workers: Run JavaScript Service Workers at the Edge

#67

Earlier quoted context omitted.

Hey Kenton, should've guessed you were behind this. Lovely design, great work. I'd be curious to learn more about the implementation (did you lift the existing SW implementation from blink somehow, or reimplement it)?

PPS - it is probably too late for this, but one of the last things I worked on at Google was Gin: https://chromium.googlesource.com/chromium/src.git/+/lkgr/gi... A bindings layer for v8 that was specifically intended to make implementing web-style APIs outside of Blink easier. At the time at least, refactoring things like SW out of Blink was ~impossible.

Doh, indeed, wish I had seen that earlier. V8's raw API is... tricky.

Re: Cloudflare Workers: Run JavaScript Service Workers at the Edge

#70
post #2

Hey 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?

Post reply on HN