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?
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.
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.
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.
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
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.
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.
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...