search

denoland / deploy_feedback

For reporting issues with Deno Deploy
https://deno.com/deploy
74 stars 5 forks source link

Don't try to be compatible with Cloudflare Workers #107

Open vwkd opened 3 years ago

vwkd commented 3 years ago

Deno Deploy claims to be compatible with other serverless platforms. Specifically, the homepage advertises "API compatible with Cloudflare Workers" and "No vendor lock-in".

This already isn't true since you can run TypeScript. Also the great idea to use Deno's native HTTP server API to allow to use Deno CLI locally [^denoapi] [^denoapi2] broke compatibility.

just feels kinda weird if some of the goals are "no vendor lock in" and "API compatible with Cloudflare Workers" but to test locally you are locked into the Deno apis - source

But more so, trying to be compatible isn't the right thing in the first place. By trying to be compatible, you're shooting yourself in the foot. By staying compatible you sign up to be a copy of the other platform. At best this cripples your platform and at worst makes it useless.

  1. You can't provide distinguishing features that would make your platform valuable over others. You can't evolve and must stay a copy of other platforms in order to stay compatible. The only distinguishing feature can be price which is hard to compete.

  2. Even if you do nothing you can break compatibility because other platforms can change themselves without asking you. You constantly need to change and copy them to stay compatible. For example, Cloudflare Workers is transitioning away from the Service Worker syntax [^swsyntax] towards using an exported class with a fetch method [^nodesm]. A polyfill [^polyfill] here isn't that simple anymore.

  3. You require yourself to follow unfortunate decisions of others. This might not seem obvious right now since serverless is largely a single product (multi-instance public FaaS, "Worker") for which it just so happens that most platforms have used the same Service Worker syntax until now. But if you decide to offer more products in the future then staying compatible can become more painful, for example #88.

Compatibility comes from the desire to make it easy for people to come to Deno Deploy and copying existing code over is easy. But you don't need compatibility. You need conversion. For example, you can offer documentation how to convert code from other platforms to Deno Deploy, you can provide a script that people can run to do this automatically, or you can even integrate that script into your UI to allow people to directly create a new project from an existing one on another platform, e.g. "Create project from Cloudflare Worker". This is what so many other platforms do, e.g. Google Docs opening Microsoft Office files, Apples "Move to iOS" Android app, etc. It's all about conversion, not compatibility.

Note, all of this doesn't mean you have to deliberately design your platform to be incompatible. You just don't put in any effort to do the opposite.

[^swsyntax]: addEventHandler("fetch", event => { ... }) [^denoapi]: "We're in the process of phasing out addEventListener("fetch", ...) in favor of Deno.listen() + Deno.serveHttp()". Source: https://github.com/denoland/deploy_feedback/issues/71#issuecomment-889760772 [^denoapi2]: "no more fetch event listener". Source: https://discord.com/channels/684898665143206084/826085979344470037/892154021165563924 [^nodesm]: export default { async fetch(request, env) { … } } in a .mjs file. Source: https://blog.cloudflare.com/workers-javascript-modules/ and https://developers.cloudflare.com/workers/learning/using-durable-objects#instantiating-and-communicating-with-a-durable-object [^polyfill]: "We will provide something you can import to polyfill fetch event locally". Source: https://discord.com/channels/684898665143206084/826085979344470037/892187811673948211

mathiasrw commented 3 years ago

Vendor lock-in is a major limitation for large organisations to start embarking on new tech.

vwkd commented 3 years ago

@mathiasrw Thank you for telling me my argument wasn't clear enough. I rewrote it to hopefully make it clearer now. Notice, the argument is independent of any specific customer, so it remains true just the same "for large organisations to start embarking on new tech". I'm happy to correct any mistake if you're able to point out a logical flaw in the argument.