Not for the time being - to allow us to run code on the edge, and be able to support many customers, we used V8 (a JavaScript engine) since it built for multi-tenant-per-process secure sandboxing, fast start time, and low overhead (a lot of this is explained in the original blog post here: https://blog.cloudflare.com/introducing-cloudflare-workers/).
We are working on improving our WebAssembly integration, and making it a first-class experience (and we launched multiple improvements with the CLI to allow you to more seamlessly develop in Rust, C and C++). Maybe one day Python WebAssembly will take off.
Have you had a look at GraalVM? Their native images [1] allow compilation of JVM-based languages into binaries with fast startup behavior and low memory footprint.
GraalVM is really awesome, but it doesn't fit what we're trying to do here. One of the key bits of architecture is that we share the VM between all of the programs; this saves on a lot of overhead. Running multiple native images would still give a copy of each runtime for each thing.
(Also, while native images may have low memory footprint themselves, that doesn't mean that the programs that use them have a low enough memory footprint; my understanding (which may be wrong!) is that the default heap size it sets is 80% of the memory of the machine you're compiling it on. You can of course tune that, but it's gonna be tough to squeeze in a memory-hungry application.)
The v8 isolates tech is super cool. It seems the other major providers might not be leveraging it in their FaaS platforms- do you have a hypothesis of why?
We're starting to see similar technologies emerge (like Fastly's Lucet). My hypotheses (please take them as that):
1. Many companies are already deeply embedded and invested in container based offerings.
2. As with every new technology, it takes some time for it to take off. Maybe others are hesitant and waiting to see how it plays out for Workers before investing (going pretty well so far :) ).
3. Possible the other providers are working on it, and haven't launched yet.
Do you have plans to provide a Workers KV interface that would allow us to search for keys, as well as view, modify and create new KV entries?
Also, it's currently only possible to avoid leaking that multiple websites belong to the same entity by creating multiple Cloudflare accounts due to the nameservers. This means that if we want to use Cloudflare workers for our 5 unique nameservers, then we would have to do a lot of unnecessary duplication. So on a somewhat unrelated note, do you have any plans to add support for adding additional nameservers to a Cloudflare account (this is currently holding us back from using Workers over Lambda, and it's something we would gladly pay for).
I’m the PM on Workers KV. We do have plans for better tooling here, though I can’t promise exact details or a timeline. I can tell you that I feel the pain of the lack of that stuff, though.
The price point may not be ideal but Business plan websites can set up branded subdomains (eg ns1.example.com, ns2.example.com).
Also, there are a limited amount of nameservers (2550 possible combinations with 50 male and 51 female nameservers I believe), so there’s probably a few thousand other accounts with the same combination of nameservers as you. This can still be a problem though, if you use a less-common TLD and/or you use pages with similar content.
It's definitely a problem for us, although it's fewer nameservers than I expected :)
No idea how I missed custom nameservers on business plan.. Hope it's something they added this year, otherwise I feel quite embarrassed.. It's too pricey for personal use (since the plans are associated with websites and not accounts) but the company will probably upgrade a few of the websites, thanks!
I've pre-registered for two subdomains, clicked the email, logged in to my account but I can't add them because it says they're "taken" (by me, presumably). How can I add the subdomains I reserved?
Are you using the email that you made the reservations with? We do the match on that.
Otherwise, if you want to shoot me an email at rita at cloudflare dot com, with the subdomains / email you signed up with, I can look into it.
It's been really interesting watching the evolution of use cases for Workers.
I would put them into three broader categories:
1. Additional functionality built on Workers: the interesting thing with Workers is that it can be a standalone function, or it can act as a proxy. That means that customers can easily add new functionality on top of existing APIs for example, without having to migrate the whole thing to Workers at once. One interesting example of that was an e-customer used Workers to add a barcode generator funcionality for one of their customers.
2. Applications built on cache: the way CDN usually works is that you build an application, and put a cache on top of it. That comes with all sorts of limitations around what you can and cannot cache. I think with a built in cache, we're going to start seeing more cases where the cache is written to from the beginning. This enables customers to do things like cache content for logged in, or paid users by doing the auth on the edge next to the cache, rather than at the origin. Or easily update only certain chunks of what's in the cache, and thus do all sorts of customization at the edge, without necessitating added latency.
3. Standalone serverless apps: there are a few very interesting examples here, one of which we'll be able to talk more openly about in a few days. I think SamKnows is a good one: they were able to build a download speedtest directly from Workers [1]. Another good one was building the reservations website for Workers.dev - we were able to get that service spun up very quickly, and have it scale infinitely to handle the influx of traffic [2]. Similarly, Cloudflare Access is built entirely on Workers (we are pretty excited about dogfooding!).
A couple random cool ones: I've seen some experimentation with ML on the edge (very much POC, and very early, but everything starts somewhere). And DNA sequencing analysis, which really blew me away [4]
>This enables customers to do things like cache content for logged in, or paid users by doing the auth on the edge next to the cache, rather than at the origin
I don't get how this would work. For someone logging in you still have to talk to a central database holding the authentication information. Really anything with a database has a similar problem if you want to enforce consistency.
To use the subdomain example, say you want to prevent two people from reserving the same name. That means the reservation from someone in Sydney has to propogate to the worker in NYC before you can confirm that it has succeeded. Otherwise, simultaneous reservations will result in two successful reservation. So you've lost the benefit of edge workers.
Sure, the initial login itself has to be done at the origin, or connect to a database, but token authentication can be done at the edge. That means that if, for example, users have to pay for articles, you can still cache the article because the authentication can be validated at the edge.
There are many benefits to running logic at the edge, even in situations like that. Scale is a big one to consider: resiliency and single point of failure are very common problems for any floodgate reservation systems. We didn't have to worry about that here.
In general, the more work you can offload to the edge, the better. There's so much logic that goes into handling a reuqest - we see many customers with conditional HTTP routing, validation, rate limiting, etc -- all requiring round trips to the origin. Now they can be done close to the user.
How is this better CDN for functions than netlify's and its dev/offline-simulating tooling ?
Maybe prices (your free tier seems overly generous) ? but Assume my interest dont go < 10K req / day, it that would be the case i would monetising somehow
I was excited to try out WASM workers (thanks again for your help in getting me set up!) but when I ran the Rust example, I realized it's only half-ready. The `request` object isn't passed into the Rust function, and there's basically no documentation about how things would work on the Rust side.
I was hoping I could get a Rust template and not have to touch any JS, just change the Rust side of things. However, it looks like all the template provides is some instruction on how to call a function without arguments, which is not very useful.
I know this might be out of scope of the template, but I think it kind of defeats the purpose of saying "We support WASM!" if it implies "but you're going to have to know JS and figure out how to actually use WASM". If I knew JS that well, I would have just used that.
I'm using workers since beta, including KV storage, it's great overall. Unfortunately recently noticed (testing for production launch) that there are rate limits in place (something around 2k requests per minute per IP for requests that go trough to origin server) - known issue it seems - https://community.cloudflare.com/t/rate-limit-on-workers/495... . I've contacted support already, ticket is marked as 'solved' but I still experience limits (429/1015 error codes). I'd love to know if it's something to be expected and if someone is planning to run tens or even hundred requests per seconds from single IP (I have bit weird API to work with that requires that) it's better to not use workers as it's not intended scenario? Or it's a matter of having more expensive Cloudflare plan (I'm on 5$/month for workers)? Would really appreciate more details on that subject as can't really change that API and will constantly run into 429 errors.
There are various mechanisms like this in place to make Workers an unattractive way to launch an attack. tadeusz_wojcik also emailed us, and we were able to raise the limit for them (and anyone else who asks!).
yep, I can confirm. Excellent communication on Zack's and Kenton's side. After limits were lifted everything is working perfectly - no more 429 errors. Thanks again!
With the release of wrangler and new docs we finally have the router app starter template. I wanted to ask if you could go one step further and share the template which would include middleware functionality implemented. By middleware I refer to what middleware stands in Django web framework.
Many of the app functionality, such as language/locale based cookies, url-level a/b-tests, etc. is shared between all the routes, and it would be nice to have such logic described somewhere in separate place, not in the route handler functions. For non-pro developers like me that'd really help.
P.S. In case no one has mentioned this yet, community is really thankful for allowing multi-script for everyone, not only enterprise users. Enterprise features for free or 5$ - that's a very generous pricing, to say the least! Thanks.
Hey - developer advocate for Workers here. Thinking a lot about this right now, prototyping a few ideas too. If you have ideas, happy to chat: kristian@cloudflare
Cloudflare Workers also supports Wasm and so supports all those languages, too, in theory.
In practice, though, Python's, Perl's, and PHP's Wasm support is extremely immature and probably won't meet the needs of a production web application today. Go is closer but still presents challenges.
Rust seems to have by far the most mature Wasm tooling (and Rust support is built-in to the Workers CLI tool). C and C++ are also reasonably usable.
I’ll have a blog post next week (on my personal blog) that you’ll find interesting! Workers + Workers KV is pretty great for this use case. KV isn’t currently available on the free tier though; the $5/month plan should be more than enough though. (I’m the PM of KV)
What I always wonder about is how one can write "non-trivial" stuff using CloudFlare workers. Don't get me wrong, I am more than intrigued by the concept, but as far as I understand, it cannot do things like connecting to a database or third party service. That makes the types of problems you can solve with it relatively small.
This is confirmed what I see if I look at the Cloudflare marketplace: it has apps for things such as cookie banners and automated GA integration, but that's not that interesting.
I might misunderstand what you mean by third party service, but today you can connect to any service on the Internet (including databases like Firestore) with Workers using fetch() [1].
We're building out our storage products -- we started with Workers KV, our distributed Key-Value store, and will to continue expanding our offering to support more use cases. You won't be able to build everything with Workers right away, but we've seen customers solve really interesting problems with it.
As we add functionality to support more and more use cases, we expect Workers to grow into a really powerful platform.
Note that Cloudflare Workers is a different product from Cloudflare Apps (which is what you see on the Marketplace). Cloudflare Apps does allow developers who want to distribute their Worker to other Cloudflare customers to do so, using Apps with Workers.
> We're building out our storage products -- we started with Workers KV, our distributed Key-Value store, and will to continue expanding our offering to support more use cases.
I have no affiliation, but would love to see a partnership with Dgraph.. Feels like a perfect match for both parties.
Fascinating, Wrangler is in Rust but installed through npm? I guess you did some market research and determined that more of your target audience would have npm installed than cargo, and then stuffed the compiled binary in an npm package or something?
It’s also just a nicer experience; let each audience install in the way that feels natural to them. And since binary releases are being built anyway, why make npm users wait on the Rust compiler.
We’re not the first to do this, by the way. This is how ripgrep is integrated into VS: Code, in my understanding.
I love the idea of Workers! The catch I ran into last year was the 1MB limit for webpacked JS files. That puts many npm packages off limits -- I ended up doing some webpack magic to stub out subdependencies I didn't need from a package that didn't support tree shaking, which is pretty far from "just works."
The upshot is if you have an idea that would be easy with dependencies, you can't reason about how difficult/possible it will be with Workers until you spend some time figuring out if the dependencies can be compressed small enough to use -- and the answer may change partway through if you need to add something.
While we haven't relaxed the 1MB restriction, we have made some changes to the way we compress and distribute your code to the edge. I'd encourage you to try again, and our new CLI[0] handles the webpacking for you.
We tried using a worker for a bit, and while it's mostly very convenient, the request/response cache API does NOT support Vary headers, which was a major dealbreaker for us.
We can probably help. Vary is usually intended to shard the cache based on parts of the request. You can do the same with the cache API - modify the cache key (quite similar to the example for caching the POST request (https://workers.cloudflare.com/docs/reference/workers-concep...), as you modify cache key to match the POST body).
I've been playing around with it for a project, and still need to experiment a bit more but the KV store integration might just work nicely for sessions (no strong consistency, but it seems to have it for the same session so ).
It has many usecases like validating a JWT, authorization for DB calls, cache layer, transforming assets, scrapping, etc. Basically the usecases where you'd normally launch a full server and be like "I need a full server for that?".
Cloudflare Workers is based on the Service Workers API, which is a W3C standard. StackPath looks like they are following this API too (though I haven't dug into their docs). So it ought to be possible to move code between these platforms. Hopefully others will follow suit as well.
Fastly has gone a different route since they support WASM exclusively (no JavaScript), but I believe they are also following an open standard for the underlying APIs (WASI).
(Disclosure: I'm the tech lead of Cloudflare Workers.)
Workers is pretty cool. I've work with the Worker team and Queue-It to get the later's SDK working there. Which has been wonderful to handle traffic at the edge.
Two things I wish were better: package installation (you have to use a compiled package instead of the GUI interface) and general docs (Mozilla's are okay, but not all are applicable to Workers).
59 comments
[ 2.8 ms ] story [ 131 ms ] threadWe are working on improving our WebAssembly integration, and making it a first-class experience (and we launched multiple improvements with the CLI to allow you to more seamlessly develop in Rust, C and C++). Maybe one day Python WebAssembly will take off.
[1] https://www.graalvm.org/docs/reference-manual/aot-compilatio...
(Also, while native images may have low memory footprint themselves, that doesn't mean that the programs that use them have a low enough memory footprint; my understanding (which may be wrong!) is that the default heap size it sets is 80% of the memory of the machine you're compiling it on. You can of course tune that, but it's gonna be tough to squeeze in a memory-hungry application.)
Also, it's currently only possible to avoid leaking that multiple websites belong to the same entity by creating multiple Cloudflare accounts due to the nameservers. This means that if we want to use Cloudflare workers for our 5 unique nameservers, then we would have to do a lot of unnecessary duplication. So on a somewhat unrelated note, do you have any plans to add support for adding additional nameservers to a Cloudflare account (this is currently holding us back from using Workers over Lambda, and it's something we would gladly pay for).
The price point may not be ideal but Business plan websites can set up branded subdomains (eg ns1.example.com, ns2.example.com).
Also, there are a limited amount of nameservers (2550 possible combinations with 50 male and 51 female nameservers I believe), so there’s probably a few thousand other accounts with the same combination of nameservers as you. This can still be a problem though, if you use a less-common TLD and/or you use pages with similar content.
You could try using the API to automate this across multiple accounts https://api.cloudflare.com.
No idea how I missed custom nameservers on business plan.. Hope it's something they added this year, otherwise I feel quite embarrassed.. It's too pricey for personal use (since the plans are associated with websites and not accounts) but the company will probably upgrade a few of the websites, thanks!
I would put them into three broader categories: 1. Additional functionality built on Workers: the interesting thing with Workers is that it can be a standalone function, or it can act as a proxy. That means that customers can easily add new functionality on top of existing APIs for example, without having to migrate the whole thing to Workers at once. One interesting example of that was an e-customer used Workers to add a barcode generator funcionality for one of their customers.
2. Applications built on cache: the way CDN usually works is that you build an application, and put a cache on top of it. That comes with all sorts of limitations around what you can and cannot cache. I think with a built in cache, we're going to start seeing more cases where the cache is written to from the beginning. This enables customers to do things like cache content for logged in, or paid users by doing the auth on the edge next to the cache, rather than at the origin. Or easily update only certain chunks of what's in the cache, and thus do all sorts of customization at the edge, without necessitating added latency.
3. Standalone serverless apps: there are a few very interesting examples here, one of which we'll be able to talk more openly about in a few days. I think SamKnows is a good one: they were able to build a download speedtest directly from Workers [1]. Another good one was building the reservations website for Workers.dev - we were able to get that service spun up very quickly, and have it scale infinitely to handle the influx of traffic [2]. Similarly, Cloudflare Access is built entirely on Workers (we are pretty excited about dogfooding!).
A couple random cool ones: I've seen some experimentation with ML on the edge (very much POC, and very early, but everything starts somewhere). And DNA sequencing analysis, which really blew me away [4]
[1] https://blog.cloudflare.com/the-samknows-cloudflare-platform... [2] https://blog.cloudflare.com/api-at-the-edge-workers-and-fire... [3] https://blog.cloudflare.com/building-serverless-apps-with-wo... [4] https://twitter.com/RobAboukhalil/status/1121095204281430016
I don't get how this would work. For someone logging in you still have to talk to a central database holding the authentication information. Really anything with a database has a similar problem if you want to enforce consistency.
To use the subdomain example, say you want to prevent two people from reserving the same name. That means the reservation from someone in Sydney has to propogate to the worker in NYC before you can confirm that it has succeeded. Otherwise, simultaneous reservations will result in two successful reservation. So you've lost the benefit of edge workers.
There are many benefits to running logic at the edge, even in situations like that. Scale is a big one to consider: resiliency and single point of failure are very common problems for any floodgate reservation systems. We didn't have to worry about that here.
In general, the more work you can offload to the edge, the better. There's so much logic that goes into handling a reuqest - we see many customers with conditional HTTP routing, validation, rate limiting, etc -- all requiring round trips to the origin. Now they can be done close to the user.
How is this better CDN for functions than netlify's and its dev/offline-simulating tooling ?
Maybe prices (your free tier seems overly generous) ? but Assume my interest dont go < 10K req / day, it that would be the case i would monetising somehow
I was hoping I could get a Rust template and not have to touch any JS, just change the Rust side of things. However, it looks like all the template provides is some instruction on how to call a function without arguments, which is not very useful.
I know this might be out of scope of the template, but I think it kind of defeats the purpose of saying "We support WASM!" if it implies "but you're going to have to know JS and figure out how to actually use WASM". If I knew JS that well, I would have just used that.
- same worker scripts are shared between CF account level and workers.dev.
- script belongs to account, not domain.
- 30 scripts limit is for account (CF/workers.dev).
- Routes for domain are unlimited.
Are all of the above statements correct?
Thanks!
Many of the app functionality, such as language/locale based cookies, url-level a/b-tests, etc. is shared between all the routes, and it would be nice to have such logic described somewhere in separate place, not in the route handler functions. For non-pro developers like me that'd really help.
P.S. In case no one has mentioned this yet, community is really thankful for allowing multi-script for everyone, not only enterprise users. Enterprise features for free or 5$ - that's a very generous pricing, to say the least! Thanks.
In practice, though, Python's, Perl's, and PHP's Wasm support is extremely immature and probably won't meet the needs of a production web application today. Go is closer but still presents challenges.
Rust seems to have by far the most mature Wasm tooling (and Rust support is built-in to the Workers CLI tool). C and C++ are also reasonably usable.
This is confirmed what I see if I look at the Cloudflare marketplace: it has apps for things such as cookie banners and automated GA integration, but that's not that interesting.
What's the long-term vision for this?
We're building out our storage products -- we started with Workers KV, our distributed Key-Value store, and will to continue expanding our offering to support more use cases. You won't be able to build everything with Workers right away, but we've seen customers solve really interesting problems with it. As we add functionality to support more and more use cases, we expect Workers to grow into a really powerful platform.
Note that Cloudflare Workers is a different product from Cloudflare Apps (which is what you see on the Marketplace). Cloudflare Apps does allow developers who want to distribute their Worker to other Cloudflare customers to do so, using Apps with Workers.
[1] More on fetch() here: https://workers.cloudflare.com/docs/reference/runtime/apis/f...
I have no affiliation, but would love to see a partnership with Dgraph.. Feels like a perfect match for both parties.
We’re not the first to do this, by the way. This is how ripgrep is integrated into VS: Code, in my understanding.
Here's a good thread where the problem package was a SOAP library depending on "request," but the same logic is easy to run into with any app: https://community.cloudflare.com/t/worker-size-limit-a-probl...
The upshot is if you have an idea that would be easy with dependencies, you can't reason about how difficult/possible it will be with Workers until you spend some time figuring out if the dependencies can be compressed small enough to use -- and the answer may change partway through if you need to add something.
Could you share your use case for Workers?
[0] https://workers.cloudflare.com/docs/quickstart/cli-setup/
It has many usecases like validating a JWT, authorization for DB calls, cache layer, transforming assets, scrapping, etc. Basically the usecases where you'd normally launch a full server and be like "I need a full server for that?".
But wouldn't very single one of these be a lock in that I cant really move freely in and out, unlike CDN.
Fastly has gone a different route since they support WASM exclusively (no JavaScript), but I believe they are also following an open standard for the underlying APIs (WASI).
(Disclosure: I'm the tech lead of Cloudflare Workers.)
Two things I wish were better: package installation (you have to use a compiled package instead of the GUI interface) and general docs (Mozilla's are okay, but not all are applicable to Workers).