Cloudflare Workers Announces Broad Language Support
blog.cloudflare.com
blog.cloudflare.com
> The main requirement for compiling to JavaScript on Workers is the ability to produce a single js file that fits in our bundle size limit of 1MB.
Compared to Lambda, that's a pretty restrictive size limit. Theirs is 50Mb, or 250Mb if you upload the package to S3. Is there any plan to change that to be closer to Lambda or will anything with larger dependencies always be out of scope?
Some of the libraries you might want to use for that numeric analysis - things like Numpy, Pandas, are pretty large. There's not really a culture of small libraries in Python like a lot of JS libraries, probably because the tradeoffs make less sense the way Python things are traditionally deployed. And there's no concept of tree shaking where dependencies get shrunk to only what you're using either - although maybe you could theoretically make that work on the JS side after transpiling the Python.
But basically, if you have really any common data analysis library from Python you're going to be in that 1-50Mb range, and if you have quite a few you can easily be over 50Mb. That is a workload that sometimes works well as a Lambda, and I'm curious if it's one Cloudflare are thinking about for Workers too.
Whilst it’s great to be billed on actual usage, it’s hard to tell how expensive a function is going to be.
For example, CloudFront has features that let me create redirects for different content to go to different origins and prefixes, but Cloudflare does not have this option. You can write a .js edge worker to do it, but I'd rather not trust the integrity of my site to some crappy javascript that I threw together, and I'd rather not have to maintain my custom code indefinitely. (Actually Cloudflare's support technicians will offer to write the custom code, but it's still not something I would like to have sitting out there outside of a VCS and SDLC, with bit rot, tech debt and other nasties lurking in the future)
You'll be able to self-serve these in the Firewall Rules engine, which is being generalized to handle "Rules" broadly speaking (including Page Rules such as redirects, rewrites, etc.).
If you drop me an email (pat at cloudflare dot com) I'll get you connected with the right PM who can put you on the beta list.
In the case of cloudfront I have only ever used it to hack up some auth controls for something real quick and dirty.
The fabled iot, self-driving car examples, as well as services like Stadia could never be run in a worker, which is why for Workers at least, speed isn’t a primary advantage.
One would still have to run databases with regional sharding in the critical locations (I'm thinking Crockroach even though I've never ran it myself). And if you're already running a database you could be running code there too, and just proxy requests through to yourself in the closest location (maybe this is what all the rage is about with workers, proxying differently depending on origin region), but i could see this being done without Turing complete language support.
EDIT: I do see how Cloudflare KV could be used as the caching layer and help there, but that's all i see. I would love to hear how someone else can/has made use of this.
I've found Fastly's Varnish recipes interesting though: https://developer.fastly.com/solutions/recipes
So instead of writing your worker in JS, you get to write it in a Python syntax except all the functions you calls are still to JS functions, some of the syntax is non-standard, and most of the Python standard library is missing.
I don't think many people are going to be terribly excited by that. You just get more headaches with very little upside. It's more like a neat demo than something you would want to seriously use.
But this announcement is all “man behind the curtain”: you’re not really writing Python, but instead JavaScript-as-Python, without any of the good parts of Python or modern JavaScript. Instead you’re likely to end up with a Franken-program that is neither.
As a way to appeal to some users, sure: this would have been a solid set of guides/tutorials on the edge of what they support. But as a major announcement, it feels like Cloudflare is trying to trick users into seeing Workers as something it’s not.
I wonder why they don't target WASM in addition to JS? In the latter case, anything that compiles to WASM would be fair game (I still wouldn't recommend Python in that case, but it would at least be less kludgy for other languages).
Check this one out: I was able to compile the lua interpreter to wasm in order to run lua code on the fly with a worker. It's absolutely a stupid toy but it's still pretty fast, and gives you a decent idea of just how powerful workers can be.
But, what I find really interesting is, we are finding it a lot easier to transpile other "managed" languages to JavaScript than to target WebAssembly. Building Python to Wasm hasn't worked well so far because the code footprint is quite large, and brings with it a whole language runtime including interpreter, garbage collector, API glue, etc. Whereas if we transpile to JS, we get V8's built-in GC, and it's much easier to call into existing high-level JS APIs. The result is nice, low code footprint, which can be distributed to thousands of edge nodes at low cost and can start up very quickly.
Both transpiling and Wasm approaches come with challenges when you want to support native-code extensions: the corresponding native library itself needs to be ported to Wasm. (Once it has, then it can be called by Wasm code or JS code, so it seems like whether or not the rest of the app is Wasm or transpiled is not critical.)
There are plans to extend Wasm to support built-in GC. Maybe then Wasm will make sense for managed languages. But, right now we're seeing Wasm is best-suited to C/C++/Rust, while transpiling is a better way to support most other languages.
(I'm the tech lead for Workers, though I wasn't directly involved in this specific project.)
But I also don't think that a light transpiler is ever going to get anywhere close to a "real" Python developer experience. Python has an enormous standard library and Transcrypt implements almost none of it. The standard library is core to what makes Python Python. If I can't use any of the built-in functions that I know and love, I don't think it's really fair to claim I'm using Python except in a very superficial way.
I think the disappointment is that I was excited to have an alternative to Google Cloud Functions and AWS Lambda (which both more or less support Python "for real"). This feels more like 20% support in my opinion.
They are the last of the major CDNs to offer this sort of functionally — code you can inject at different points along the request.
Yes, they did a huge service to the internet by giving everyone free SSL but their control panel is maddening and it’s very hard to understand what each switch/knob actually is doing behind all of the marketing speak.
I think the free DNS are great too but I see all this worker stuff as a catch up “we do this too” feature and not a new thing. They aren’t doing it better than anyone else.
That is just false. There are many others, like CloudFront Edge Lambda.
Eh? Which other CDNs let normal (non-big-enterprise) users deploy Turing-complete code to the edge before Workers was launched in 2018?
I can only think of Lambda@Edge, which itself was quite new at the time. But maybe I'm forgetting some. Which ones are you thinking of?
Really? I find their control panel to be quite straightforward and intuitive. Certainly more so than AWS, GCP or Azure shudder