Cloudflare Workers
workers.cloudflare.com
workers.cloudflare.com
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.
[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.
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/
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.
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.)
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?".
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).
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.