Live data from Hacker News

Python Cloudflare Workers

blog.cloudflare.com

91–100 of 101 posts

Re: Python Cloudflare Workers

#91
post #9

Clouflare has a lot of great stuff for hosting and databases but I think they haven't done a great job marketing themselves as developer platform which has lead to platforms like Vercel, Netlify taking significant mindshare. Tangential: does Cloudflare provide container hosting service agnostic of language -- something like Google Cloud Run?

> something like Google Cloud Run?

No but it would be awesome.

I've been using Workers for about 4 years in production and love them but containers are still where I run most of my apps.

Re: Python Cloudflare Workers

#92
post #32
post #16

Can we just get full node runtime? Cloudflare is amazing, but without a full node runtime, we (and most of the usual apps) can't switch from things like Vercel/Netlify to Cloudflare.

The unique architecture of our runtime is what enables most of our competitive advantages. It's what lets us run your application in hundreds of locations around the world while also charging less than competing serverless platforms. If we used a full Node runtime, we would need to charge a lot more money, or only run your app in a couple central locations, or both. So, no, we can't just offer full Node. However, we…

I pick the 2nd. Few apps needs to run in the edge.

Re: Python Cloudflare Workers

#93

Earlier quoted context omitted.

Your comment would have been great without: > So, no, we can't just offer full Node. (Sounds a bit snotty)

How else would you write that? Would this be better? "Thus, no, we can't just offer full Node." Is it the use of "so" that is off limits? Or is simply providing a concise conclusion inappropriate? I don't see what part of that quote is "snotty".

Omitting it

No PR person would have included that line

Re: Python Cloudflare Workers

#94
Tried this out today and it was great, was very quick to get up and running!

One question though – does anyone know how I can get my local dev environment to understand the libraries that are built-in to CFW's Python implementation? e.g. there is an `asgi` library that I do not want my linter to flag as unknown, but as it only exists at runtime in the `on_fetch` handler (and isn't actually present in my local dev machine, I couldn't figure this out.

Re: Python Cloudflare Workers

#95
post #77
post #66

Earlier quoted context omitted.

I get the sense that Cloudflare Workers is targeted almost exclusively at existing customers of Cloudflare, who have a “legacy” app proxied through Cloudflare DNS, who use Page Rules and Firewall Rules and the like. For these customers, Workers are an incremental optimization of an existing app — shifting some work to the edge, or allowing some systems to have a previously-internal backend stripped out, leaving them…

Workers started with that use case, but these days we're definitely aiming to be a general-purpose platform for app hosting, especially for new apps. It sounds like we're not getting that message across very well.

Not just the message; the docs, and even the internal structure of the Workers section of the CF dashboard, are also lacking on describing how to approach building a greenfield app using Workers.

I recently tried to build a Worker-based app for a personal project, after a few months of not having touched Workers, having only previously used them at $work for the "decorator of legacy backend" use-case. I knew what capabilities Workers had, and knew exactly what I wanted to do... but getting it up and running was still confusing!

One specific example: trying to figure out how to get a production-quality workflow for maintaining and deploying a worker.

- It's actually hard to notice the "Edit Code" button on a Worker's overview. I flipped through all the other tabs twice before noticing it.

- Then, after getting in there, I remembered how useless the web IDE is for testing, when the domain is fronting a bucket named after a custom domain associated with a Workers Route rather than with the canonical name of the worker. So I wanted to set up the worker to deploy from a Github Action.

- But how do I do that? Can I go into "Integrations" and select "Github Repo"? (No.)

- I figure that the Wrangler CLI will set me up for doing on-push deploy. So I download it. (It doesn't.)

- Also, the CF Workers docs tell me to install the wrangler NPM package and run `npx wrangler init`. But once I do, that command itself tells me that it's deprecated, and that I'm supposed to run `npm create cloudflare\@2.5.0`.

- I read through the Wrangler docs and figure out that it's a "build a local slug from your worktree and push it" kind of deployer, rather than a "build a deploy from a git ref and push it" kind of deployer. So I figure, to enable GitOps deploys, I'll need an action that runs Wrangler itself on Github Actions. I search the Workers docs, and the Wrangler CLI docs (separate site) for this. Neither one mentions this possibility.

- I end up just googling "wrangler github action" and finding https://github.com/cloudflare/wrangler-action. Great! I add it to the new Github repo that Wrangler created, and add the relevant secret.

You know what this could have been instead? A button on the Workers dashboard — or even on a CF marketing landing page! — that 1. SSOs the user into Github; 2. automates the creation of a new repo that gets pre-populated with a Worker skeleton project + this Wrangler workflow already committed to it + the correct relevant secret already bound into the repo; and then 3. drops me into either the Workers IDE (modified to connect to the repo by creating PR branches + committing to them for "drafts", and merging those PRs for "publish"), or alternately, into Github Codespaces with the Workers IDE stuff reimplemented as a VSCode preview plugin. (And same for Gitlab, etc.)

Re: Python Cloudflare Workers

#96
post #95
post #77

Earlier quoted context omitted.

Workers started with that use case, but these days we're definitely aiming to be a general-purpose platform for app hosting, especially for new apps. It sounds like we're not getting that message across very well.

Not just the message; the docs, and even the internal structure of the Workers section of the CF dashboard, are also lacking on describing how to approach building a greenfield app using Workers. I recently tried to build a Worker-based app for a personal project, after a few months of not having touched Workers, having only previously used them at $work for the "decorator of legacy backend" use-case. I knew what cap…

Thanks, this is great feedback.

Cleaning this up is actually something I've been hoping to focus on personally in the coming months. Let's see what we can do...

Re: Python Cloudflare Workers

#98

This is awesome, I'm happy that Cloudflare is adding more attention into running Python via WebAssembly at the Edge. I'll try to summarize on how they got it running and what are the drawbacks that they have from their current approach (note: I have deep context on running Python with WebAssembly at the Edge as part of my work in Wasmer). Cloudflare Workers are enabling Python at the Edge by using Pyodide [1] (Python…

As a side note, Wasmer offers an Edge product that has none of the drawbacks commented when running Python in Cloudflare Workers, providing incredibly fast cold-start times:

https://wasmer.io/templates?language=python

Re: Python Cloudflare Workers

#99

This is awesome, I'm happy that Cloudflare is adding more attention into running Python via WebAssembly at the Edge. I'll try to summarize on how they got it running and what are the drawbacks that they have from their current approach (note: I have deep context on running Python with WebAssembly at the Edge as part of my work in Wasmer). Cloudflare Workers are enabling Python at the Edge by using Pyodide [1] (Python…

As a side note, Wasmer offers an Edge product that has none of the drawbacks commented when running Python in Cloudflare Workers, providing incredibly fast cold-start times: https://wasmer.io/templates?language=python

Wasmer claims to cold start in 50ns. This is obviously impossible: That's 1000x faster than an NVMe read, which is about the fastest cold storage you can get.

At least make your claims credible before posting them in competitors' HN threads.

Re: Python Cloudflare Workers

#100
post #99

Earlier quoted context omitted.

As a side note, Wasmer offers an Edge product that has none of the drawbacks commented when running Python in Cloudflare Workers, providing incredibly fast cold-start times: https://wasmer.io/templates?language=python

Wasmer claims to cold start in 50ns. This is obviously impossible: That's 1000x faster than an NVMe read, which is about the fastest cold storage you can get. At least make your claims credible before posting them in competitors' HN threads.

> Wasmer claims to cold start in 50ns

I believe this statement was based on Wasmer Edge product page, which was mainly measuring instantiation time if the module is already loaded in the Edge Node (which can be assumed true for most common programs such as WinterJS, static-web-server and more). As it seems the 50ns timing was not well understood, we updated our product page to reflect a more accurate timing thanks to your feedback.

We can get into sub-millisecond cold starts (loading a module from disk, instantiating it and serving the first request) for the best case scenario, a timing now properly reflected in the Wasmer Edge product page.

In any case, and to be clear, we can get into much faster cold starts than the full second than Cloudflare Workers currently offers for Python. Wasmer Edge should be at least 10x faster than Cloudflare Workers for Python cold starts, with a cold-start time of less than <100ms. You can also expect to see much faster cold start times in next releases :)

Post reply on HN