Denoflare is a way to run Cloudflare Workers locally, so not something that directly compares to Deno Deploy, which is a product used to run your code globally close to users.
Denoflare looks like a way to develop Cloudflare Workers locally, possibly as an alternative to Cloudflare's Wrangler CLI [0]. The Wrangler CLI has `wrangler dev` that serves a similar purpose by actually uploading local code to Cloudflare to run in the "real" Workers environment. Denoflare instead emulates it locally using Deno, given that both Workers and Deno provide Web Platform APIs.
There's also Miniflare [1], which emulates a large portion of the Cloudflare Workers runtime and adjacent services like Durable Objects and the Key/Value store locally. Miniflare was recently promoted to an official Cloudflare Workers project [2].
Perhaps it used to, but today `wrangler preview` previews your worker in the cloud using the "preview service", and `wrangler dev` uses a private tunnel to an edge node to serve local development requests [0]. Neither of them use Node.
> wrangler dev is a command that establishes a connection between localhost and an edge server that operates your Worker in development. A cloudflared tunnel forwards all requests to the edge server, which continuously updates as your Worker code changes. This allows full access to Workers KV, Durable Objects, etc. This is a great way to easily test your Worker while developing.
Ah that's right. I was misremembering; it was the jest test suite that ran with node and had to contend with differences between node and Workers' V8 engine. I don't suppose anyone's come up with anything better?
It's almost perfect for a url shortener, even with custom urls if paired with the kv store. Trivial, I know, but go look at what some people pay for these services.
Similar to URL shorteners, I've had cases where I wanted to allow users to create a “share link” that persists data in an app that otherwise didn't have persistence. Typically I've used a Lambda job that uploads to a public S3 bucket, but next time it comes up I plan to try Workers.
I've actually used it to bypass inherent (imo) shortcomings in Firebase dynamic links. And add custom functionality, such as allowing for single-letter query strings to append utm parameters (?t -> utm_source twitter). I also didn't want the smart detection it tries to use for mobile devices with its JS-enabled page, so the worker scrapes the correct URL from the page as well
I run multiple physical data centers with thousands of individual machines that operate autonomously. I proxy/cache API hits to the Github API so that each machine can download a small binary app that runs on each of them that works to ensure each machine is operating as it should.
It is a whole self-upgrade process that involves using Github CI to do the binary build on commit (and run the unit tests, of course) to produce a new version.
The app (running on each box) periodically queries a versions file stored in git (also proxied through a worker) so they know which build to download. I can segment versions of the app across CIDR so that I can do channel (alpha/beta/stable) based releases for testing.
It is a pretty epic solution since the workers only cost $5/month and totally saves my bacon with just a small bit of simple code.
The $5/month makes me suspicious. Is it really that cheap forever, or just until they capture enough of the market they can up that cost without people jumping ship.
really great someone finally makes an effort to build something like miniflare based on deno. though as with miniflare i miss the official goal to not only be a test/simulation project but an official way to run your cf compatible functions in production.
Author here: yes this is exactly the goal of denoflare, I started it before miniflare existed, and Deno seemed much more aligned with the Cloudflare Worker model than Node, honestly.
With denoflare, you can serve your Cloudflare Worker script locally and deploy it to Cloudflare with a single tool, without the need for Wrangler, Node, NPM, or a separate bundler.
Also makes writing/deploying ESM-module-based workers trivial - can even deploy a CF Worker to your own account from a URL, e.g. [1]
thats really awesome. but why not update the docs to refelct that? they only mention "develop and test" locally. Are you afraid cloudflare will see this development as a threat?
Cloudflare Workers aren't running Node or Deno though, they just use the V8 runtime and implement a few web APIs (this is oversimplified of course but you get what I mean)
Correct - denoflare scripts are served in a permissionless Deno worker locally - even the Deno namespace is unavailable, just like on Cloudflare.
Developing the worker in Deno brings you the benefit of first-class support for typescript and ESM-modules in your worker, and no need for Node polyfills.
Once you deploy your worker, it runs like any other javascript worker on the magical Cloudflare V8 worker runtime.
Deno’s company was planning to release something like this, called Deno Deploy. (Not sure of the status of that product)
Ryan talked about it one hour in to the changelog interview published in June.
How is Denoflare compare / contrast with that?
[1] 1:00:00 @ https://podcasts.apple.com/us/podcast/the-changelog-software...
Deno Deploy is in public beta right now: https://deno.com/deploy
Denoflare is a way to run Cloudflare Workers locally, so not something that directly compares to Deno Deploy, which is a product used to run your code globally close to users.
Not affiliated with Deno or Denoflare, but you can try Deno Deploy today! See https://deno.com/deploy/. Here's a recent status update from the blog: https://deno.com/blog/deploy-beta3/
Denoflare looks like a way to develop Cloudflare Workers locally, possibly as an alternative to Cloudflare's Wrangler CLI [0]. The Wrangler CLI has `wrangler dev` that serves a similar purpose by actually uploading local code to Cloudflare to run in the "real" Workers environment. Denoflare instead emulates it locally using Deno, given that both Workers and Deno provide Web Platform APIs.
There's also Miniflare [1], which emulates a large portion of the Cloudflare Workers runtime and adjacent services like Durable Objects and the Key/Value store locally. Miniflare was recently promoted to an official Cloudflare Workers project [2].
[0] https://github.com/cloudflare/wrangler
[1] https://miniflare.dev/
[2] https://twitter.com/_mrbbot/status/1441143456106094595
I switched from wrangler to miniflare for my stuff. Highly recommend. Super easy...
I thought “wrangler dev” ran locally with node and “wrangler preview” ran in the cloud?
Perhaps it used to, but today `wrangler preview` previews your worker in the cloud using the "preview service", and `wrangler dev` uses a private tunnel to an edge node to serve local development requests [0]. Neither of them use Node.
> wrangler dev is a command that establishes a connection between localhost and an edge server that operates your Worker in development. A cloudflared tunnel forwards all requests to the edge server, which continuously updates as your Worker code changes. This allows full access to Workers KV, Durable Objects, etc. This is a great way to easily test your Worker while developing.
[0] https://developers.cloudflare.com/workers/cli-wrangler/comma...
That's correct, and it has always worked that way. Wrangler has never used Node to run Workers. Miniflare is the tool that runs locally with Node.
Thanks!
Ah that's right. I was misremembering; it was the jest test suite that ran with node and had to contend with differences between node and Workers' V8 engine. I don't suppose anyone's come up with anything better?
Miniflare is an amazing piece of software, I'm so glad Cloudflare is taking an official role with it.
What do you guys use Cloudflare Workers for ?
It's almost perfect for a url shortener, even with custom urls if paired with the kv store. Trivial, I know, but go look at what some people pay for these services.
Similar to URL shorteners, I've had cases where I wanted to allow users to create a “share link” that persists data in an app that otherwise didn't have persistence. Typically I've used a Lambda job that uploads to a public S3 bucket, but next time it comes up I plan to try Workers.
I've actually used it to bypass inherent (imo) shortcomings in Firebase dynamic links. And add custom functionality, such as allowing for single-letter query strings to append utm parameters (?t -> utm_source twitter). I also didn't want the smart detection it tries to use for mobile devices with its JS-enabled page, so the worker scrapes the correct URL from the page as well
I run multiple physical data centers with thousands of individual machines that operate autonomously. I proxy/cache API hits to the Github API so that each machine can download a small binary app that runs on each of them that works to ensure each machine is operating as it should.
It is a whole self-upgrade process that involves using Github CI to do the binary build on commit (and run the unit tests, of course) to produce a new version.
The app (running on each box) periodically queries a versions file stored in git (also proxied through a worker) so they know which build to download. I can segment versions of the app across CIDR so that I can do channel (alpha/beta/stable) based releases for testing.
It is a pretty epic solution since the workers only cost $5/month and totally saves my bacon with just a small bit of simple code.
The $5/month makes me suspicious. Is it really that cheap forever, or just until they capture enough of the market they can up that cost without people jumping ship.
The pricing is actually $0.15/million requests per month.
$5 is minimum monthly payment.
They also have a free plan with 100,000 requests per day.
I built an API proxy using a CF Worker today. The deploy takes only 2 seconds. Its speed is its killer feature.
See: https://workers.cloudflare.com/built-with
I wish it wasn't based on a JS backend. For example, if you write Python, it gets translated to JS using Transcrypt. That just feels wrong to me.
Workers can run WASM (as can deno). So, you're right at home with c, cpp, and rust (and any other language that can compile to wasm)
Is that actually any slower? Python is so slow compared to JavaScript I wouldn't be surprised if transpiling it sped it up!
really great someone finally makes an effort to build something like miniflare based on deno. though as with miniflare i miss the official goal to not only be a test/simulation project but an official way to run your cf compatible functions in production.
Author here: yes this is exactly the goal of denoflare, I started it before miniflare existed, and Deno seemed much more aligned with the Cloudflare Worker model than Node, honestly.
With denoflare, you can serve your Cloudflare Worker script locally and deploy it to Cloudflare with a single tool, without the need for Wrangler, Node, NPM, or a separate bundler.
Also makes writing/deploying ESM-module-based workers trivial - can even deploy a CF Worker to your own account from a URL, e.g. [1]
[1] denoflare push --name webtail https://raw.githubusercontent.com/skymethod/denoflare/v0.3.0...
thats really awesome. but why not update the docs to refelct that? they only mention "develop and test" locally. Are you afraid cloudflare will see this development as a threat?
What I didn't see in the docs that would be of great interest is benchmarks for Deno in Cloudflare workers versus vanilla Node.
Cloudflare Workers aren't running Node or Deno though, they just use the V8 runtime and implement a few web APIs (this is oversimplified of course but you get what I mean)
Correct - denoflare scripts are served in a permissionless Deno worker locally - even the Deno namespace is unavailable, just like on Cloudflare.
Developing the worker in Deno brings you the benefit of first-class support for typescript and ESM-modules in your worker, and no need for Node polyfills.
Once you deploy your worker, it runs like any other javascript worker on the magical Cloudflare V8 worker runtime.