Cloudflare Workers: Run JavaScript Service Workers at the Edge • Hacker News Board

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

#111

Post by kentonv » Fri, Sep 29, 2017, 10:30 PM UTC

eloff wrote: post #109

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…

I would very much like to see a pay-as-you-go cloud pricing model that allows you to pay to go over these limits (within reason.) For the use case I'm envisaging, filtering largish buffers of Cap'N Proto data (I'm tickled that both of these things are your babies!) I can use streaming fetch API to stay within the memory limit, but the 50ms limit would really be a hard wall that would cause requests to fail on larger…

I'd love to hear more about your use case (especially since it involves Cap'n Proto!). E-mail me? (kenton at cloudflare)

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

#112

Post by kentonv » Fri, Sep 29, 2017, 10:34 PM UTC

valentinvieriu wrote: post #110

Great addition to your services. I really want to see the pricing. Also I'm quite excited to see how this will play along with the apps concept. Do you plan also to introduce a monetisation system for the apps? It will be a good incentive then for developers to get some nice income.

As a matter of fact, the monetization part already exists: Cloudflare Apps is a thing today, including paid apps. Today, though, they are limited to injecting client-side code. Once Cloudflare Workers are integrated with Apps, they'll be able to include server-side code too. https://www.cloudflare.com/apps/

PS. There's an investment fund targeting Cloudflare App developers: https://www.cloudflare.com/fund/

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

#113

Post by richdougherty » Sat, Sep 30, 2017, 12:15 AM UTC

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!

Hi Kenton - awesome new feature!

In the blog post you talk about the trade-offs of using JavaScript vs other options like containers. I thought you might be interested in this comparison of using JavaScript vs other sandboxing options.

https://blog.acolyer.org/2017/08/22/javascript-for-extending...

> Hosts of V8 can multiplex applications by switching between contexts, just as conventional protection is implemented in the OS as process context switches… A V8 context switch is just 8.7% of the cost of a conventional process context switch… V8 will allow more tenants, and it will allow more of them to be active at a time at a lower cost.

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

#114

Post by peterwwillis » Sat, Sep 30, 2017, 12:56 AM UTC

kentonv wrote: post #97

peterwwillis wrote: post #96

- Is it "Cloudflare Workers" or "Cloudflare Service Workers"? A "Cloudflare Worker" is JavaScript you write that runs on Cloudflare's edge. A "Cloudflare Service Worker" is specifically a worker which handles HTTP traffic and is written against the Service Worker API. Consufing naming convention. Now you have to say 'worker worker' or 'non-service worker' so nobody has to wonder if you meant 'service worker' when you…

Not really, because once there are workers other than Service Workers, they'll have their own names. To be clear, a Service Worker is one kind of Worker. At the moment it's the only kind, but we could introduce others in the future. For instance, maybe we'd introduce a "DNS Worker" that responds to DNS requests. Also note we didn't invent these terms. "Workers" and "Service Workers" are W3C standards.

Ok. If you're going to have a DNS worker, wouldn't it make more sense to call the http one the HTTP worker? Isn't DNS a service?

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

#115

Post by comex » Sat, Sep 30, 2017, 1:04 AM UTC

chrismorgan wrote: post #42

kentonv wrote: post #30

Earlier quoted context omitted.

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…

That’s about what I expected; thanks. Just for reference for people reading this: rust-bindgen can produce bindings to C++ code these days, though that gets you an unsafe library; you’d want to build another thin layer on top of it to nail down the ownership semantics so that you can provide a safe interface.

bindgen’s C++ support is better than it used to be, but still pretty limited, e.g. no support for inline functions, or their moral equivalent, methods defined within a class definition (which most C++ code has a ton of). And even if it works, to quote the documentation:

> using [C++] types in Rust will be nowhere near as nice as using them in C++. You will have to manually call constructors, destructors, overloaded operators, etc yourself.

source: https://github.com/rust-lang-nursery/rust-bindgen/blob/maste...

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

#116

Post by kentonv » Sat, Sep 30, 2017, 2:43 AM UTC

peterwwillis wrote: post #114

kentonv wrote: post #97

Earlier quoted context omitted.

Not really, because once there are workers other than Service Workers, they'll have their own names. To be clear, a Service Worker is one kind of Worker. At the moment it's the only kind, but we could introduce others in the future. For instance, maybe we'd introduce a "DNS Worker" that responds to DNS requests. Also note we didn't invent these terms. "Workers" and "Service Workers" are W3C standards.

Ok. If you're going to have a DNS worker, wouldn't it make more sense to call the http one the HTTP worker? Isn't DNS a service?

We called it a Service Worker because the API follows the W3C standard Service Worker spec:

https://www.w3.org/TR/service-workers-1/

https://developer.mozilla.org/en-US/docs/Web/API/Service_Wor...

I agree that the naming is not completely intuitive, but these are the names that exist and so we're using them.

I'm not aware of any similar spec for DNS workers so I figure we'll use whatever name we want there.

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

#117

Post by kentonv » Sat, Sep 30, 2017, 2:58 AM UTC

richdougherty wrote: post #113

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!

Hi Kenton - awesome new feature! In the blog post you talk about the trade-offs of using JavaScript vs other options like containers. I thought you might be interested in this comparison of using JavaScript vs other sandboxing options. https://blog.acolyer.org/2017/08/22/javascript-for-extending... > Hosts of V8 can multiplex applications by switching between contexts, just as conventional protection is implemented i…

Yes, that sounds like exactly the conclusions we came to. :)

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

#118

Post by tmccrmck » Sat, Sep 30, 2017, 3:03 AM UTC

comex wrote: post #115

chrismorgan wrote: post #42

Earlier quoted context omitted.

That’s about what I expected; thanks. Just for reference for people reading this: rust-bindgen can produce bindings to C++ code these days, though that gets you an unsafe library; you’d want to build another thin layer on top of it to nail down the ownership semantics so that you can provide a safe interface.

bindgen’s C++ support is better than it used to be, but still pretty limited, e.g. no support for inline functions, or their moral equivalent, methods defined within a class definition (which most C++ code has a ton of). And even if it works, to quote the documentation: > using [C++] types in Rust will be nowhere near as nice as using them in C++. You will have to manually call constructors, destructors, overloaded o…

Thanks. Sometimes I feel like the "just use X" folks don't really think about the problem at hand, not to mention how trivializing it can be. And this is coming from a Rust fan and someone who uses bindgen.

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

#119

Post by js2 » Sat, Sep 30, 2017, 3:45 AM UTC

lima wrote: post #99

js2 wrote: post #46

This 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…

You misspelled announcement though. And addition. Sorry, had to :)

Phone typos. Too late to fix. Oh well, can’t win them all.

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

#120

Post by pbowyer » Sat, Sep 30, 2017, 7:03 AM UTC

jgrahamc wrote: post #24

tyingq wrote: post #23

Very nice. Are there plans to expand on it? For example, some way to allow state to be kept at the edge as well.

Yes. We plan to. We are releasing this to find out precisely what people need.

Some way to implement cache tagging and fast invalidation based on tags (a la Fastly) would be good. Without storage I can't see a way to keep a hash of currently valid tags - but I will play!