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

Cloudflare Workers: Run JavaScript Service Workers at the Edge

blog.cloudflare.com

Post reply on HN
Print view View original

71–80 of 134 posts

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

#71

Post by kentonv »

abritishguy wrote: post #68
kentonv wrote: 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!

Is there any way to store state?

So, there is the HTTP cache. It turns out a lot of storage use cases are actually answered by the cache. E.g. say you need some lookup table that changes every five minutes -- make it cacheable, max-age=300, and have your worker load it from cache.

Of course, that's not the answer to everything. We don't plan to offer other storage in v1 but we are definitely thinking about it for the future.

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

#73

Post by kentonv »

corobo wrote: post #55
kentonv wrote: post #13

Earlier quoted context omitted.

Yes. Currently you get at most 50ms CPU time per request, and memory usage of your Javascript VM is limited to 128MB. These numbers may change before launch. In practice, though, a typical script probably uses much less than 1ms of CPU time per request and probably needs only a couple megs of RAM. Because we're applying limits on the level of a V8 Isolate, not on an OS process, the limits go a lot further. Keep in mi…

What happens if the limits are reached? Does the end user get an error or does the request proceed as it would without the script?

Currently, an error, because default handling might not be correct in many cases -- imagine a script implementing access control or expanding an HTML template. But I'd be open to the idea of letting the script call, like, `event.fallbackOk()` upfront to specify that default behavior as a fallback is safe.

Note that the 50ms is CPU time, not wall time. This is actually a pretty huge amount of time for handling one request.

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

#74

Post by kentonv »

tolmasky wrote: post #66
kentonv wrote: post #14

Earlier quoted context omitted.

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?

> What are you embedding v8 into exactly?

C++ code.

Yeah, I know...

> What happens if I figure out a buffer overflow in v8?

You report it to Google for $15,000. ;)

More seriously, though, this is something we've spent a huge amount of effort worrying about. There are many layers of sandboxing and mitigation, including an incredibly tight seccomp filter, namespaces, cgroups, ASLR, architectural changes to keep sensitive secrets away from risky processes, etc. But we still worry and will continue to add more safeguards.

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

#75

Post by maybeiambatman »

djhworld wrote: post #65

Is this similar to Amazon's Lambda@Edge?

Sounds like it. I think Cloudflare's edge (no pun intended) is going to be their 110+ locations to host this. As opposed to Amazon's 93 I believe? (If all cloudfront spots support lambda@edge that is) https://aws.amazon.com/cloudfront/details/

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

#76

Post by steveklabnik »

kentonv wrote: post #30
chrismorgan wrote: post #25

Earlier quoted context omitted.

Point of curiosity: why did you go with C++ instead of Rust?

V8's API is C++. While bindings exist in other languages, they don't always expose everything and don't always keep up with V8's frequent API changes. I felt it was essential that we bind closely to V8, being able to use all of its features, and that we be able to track closely to the latest stable release. Also, I personally have decades of experience in C++ and wasn't sure this should be the project where I work on…

https://www.neon-bindings.com/ is written by Dave Herman, you might find it interesting to play with :)

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

#77

Post by manigandham »

boundlessdreamz wrote: post #44

offtopic: can cloudflare be used as a CDN for just assets? The cloudflare docs talk only about using it as CDN for an entire site.

CDNs dont make a distinction. It's a reverse proxy so any HTTP request can be cached. Cloudflare has a list of standard filetypes supported: https://support.cloudflare.com/hc/en-us/articles/200172516-W...

They do have rules on large files though and prefer you use it for typical web content like text and images.

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

#78

Post by drdaeman »

Oh my. Is there any form of persistence, present or planned?

If there is - this means that there (eventually) will be a way to have logs from the edge servers. I'm just thinking about a worker that would collect the requests and responses data in some circular buffer, and try to push it to the origin server. Eventually, the data will get through, so no CDN-returned 52x ("web server is not responding" etc) errors would go unnoticed.

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

#79

Post by j_s »

Paging HN user johansch from his comment on the Cloudflare Apps mitm JavaScript injection discussion 3 months ago:

johansch: All I want is my code running on your nodes all around the world with an end-to-end ping that is less than 10 ms to the average client

dsl: Akamai Edge Compute is what they are asking for

https://news.ycombinator.com/item?id=14650025

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

#80

Post by kentonv »

drdaeman wrote: post #78

Oh my. Is there any form of persistence, present or planned? If there is - this means that there (eventually) will be a way to have logs from the edge servers. I'm just thinking about a worker that would collect the requests and responses data in some circular buffer, and try to push it to the origin server. Eventually, the data will get through, so no CDN-returned 52x ("web server is not responding" etc) errors woul…

We won't offer writable storage at the edge in v1, but you could always make a background request to push these events back to some log service you maintain (on separate infrastructure from your main service to make simultaneous outages unlikely). Note that you can make background requests that happen after the main response has already returned (but still subject to the per-request CPU limits, etc.).

We're thinking about how to do writable storage, but it's tricky, since one thing we don't want is for developers to have to think about the fact that their code is running in hundreds of locations.

Post reply on HN