miniflare VS serverless-wsgi

Recently Cloudflare introduces Miniflare. As its name suggests, Miniflare is a feature-rich but miniature version of Cloudflare worker. Miniflare is a simulator that provides an environment for developing and testing Cloudflare worker scripts locally. Miniflare is written in typescript and supports most of the Cloudflare worker features like the KV database, durable objects, WebSockets, etc.

Another implementation of the above is Cloudfare workers you might be capable of grasp some ideas from here https://miniflare.dev

Is there an ETA on Miniflare v3? Ran into a problem recently using overlapping keys with forward slashes as they were not sanitized properly: https://github.com/cloudflare/miniflare/issues/167

I used hono (a wrapper around miniflare) to handle some of the boilerplate around request and routing logic. It's also refreshingly fast! 🔥

The simple explanation is that I'm proposing use of the Service Worker API. Cloudflare offers a flat, free, 100k requests a day if you can keep it cutting edge, has local development and testing options with miniflare and a key/value (KV) store.

Slshx is a library for building strongly-typed Discord commands (https://discord.com/developers/docs/interactions/application...) that run on Cloudflare Workers (https://workers.cloudflare.com/), using a React-inspired syntax (hooks and JSX). It supports all Discord command types/options, autocomplete and interactive message components. During development, it automatically deploys your commands whenever you change your code.

I created this because I think Cloudflare Workers are a great fit for hosting Discord commands, but there wasn't an easy way to get started that had a fun development experience. I also wanted to see what a Miniflare-first (https://github.com/cloudflare/miniflare) library could look like.

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, both of which 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. 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

If it helps, the concept is super-simple and reimplementing such a service won't be hard if anyone tries to make it interoperable with Workers. Miniflare (a dev environment for Workers) implements it in just over 200 loc[0], with the only backend beint Workers KV for data storage (<500 loc if you count that).

0: https://github.com/cloudflare/miniflare/blob/master/src/modu...

I hope your head is not spinning. Now you might think, Wait, I have a Flask or my Django app where the framework is taking care of the endpoints in my python code. Do I need to recreate several lambdas? A valid question. Luckily, there is also an awesome Plugin for that.

> But two years from now CloudFlare could be doing the exact same stuff Amazon is doing now, and customers are locked in again, because no source code.

I hear this argument often but it always rings hollow.

A friend had a first gen iPod – when he wanted to switch, he discovered that the music he bought on iTunes couldn't be moved anywhere else because of DRM. That's lock in.

But this morning I was looking at the source code of an app built against the Serverless framework[1] and what I'm seeing is a bog standard WSGI application that uses a library to transform the inbound AWS "proprietary bits" into WSGI[2]. I'm not worried about lock-in there because all API Gateway + Lambda do is "translate an HTTP request into a JSON object and toss it to an app"[3] – what source code am I missing? The underlying Lambda/APIGW code? OK, but do I need it to run it myself? Not really.

Many – most? – AWS products tend towards this analysis. S3 is so locked in that, what, we now have multiple very high quality alternatives that are API compatible?

The real risk of cloud vendor lock in, from where I sit, comes from egregious pricing models that make it cheap to get data in & expensive to push data out. But I'm not sure Cloudflare has the juice to make this play work: egress pricing is essentially free money for AWS, so they've got lots of room to cut costs there – from what I've heard from people who negotiate real bills with AWS, they're very happy to give you discounts there.

[1]: https://github.com/serverless/examples/tree/master/aws-pytho...

[2]: https://github.com/logandk/serverless-wsgi

[3]: https://docs.aws.amazon.com/apigateway/latest/developerguide...