Maybe, but I think it's probably more related creating a larger Workers ecosystem.
Right now, you can't use most NPM modules on CF Workers since this is a custom runtime which is also pretty barebones (probably by design).
Deno in comparison offers a rich standard library which solves plenty, but they are also working on a compat layer for Node modules. And the Deno ecosystem is also growing, probably because you can run it anywhere.
Thanks. Indeed, I always expected to release this code eventually and I'm very happy that it's finally happened. Also very happy we could do it under an actual open source license.
We've always designed Workers around open standard APIs, so even without this, Workers-based code should not be too hard to port to competing runtimes. But, this makes it much easier to move your code anywhere, with bug-for-bug compatibility.
You can't build a successful developer ecosystem that has only one provider. We know that. We'd rather people choose Cloudflare for our ability to instantly and effortlessly deploy your application to hundreds of points of presence around the world, at lower cost than anyone else. :)
Thank you for releasing this! Had a question: if I have worker code that uses other Cloudflare storage APIs like KV or R2, what would you recommend as far as shimming those calls so this code could run via workerd (but, for example, just use basic process-local in-memory storage for now.) Is that doable? For my use case durability isn’t that important and I’d like to offer people the ability to self host my code via workerd.
workerd includes implementations of the KV and R2 binding APIs, which convert all your calls into HTTP requests under the hood. You can point that at another Worker or to a separate HTTP service to implement the storage behind them. We plan to provide some example implementations in the future that store to disk or a database.
I'm curious on the use cases for self hosting? Ie i have a heavy interest in self hosting. I also find workerd very interesting. Though i'm struggling to think of reasons why i'd build my apps around workerd instead of just a process.
If i was dedicated to WASM, Perhaps workerd might be a better solution than wasmer, unsure.
Thanks for workerd! I saw a tweet from you mention that workerd could be used as a reverse-proxy (a la nginx), but the github readme is scant on the details and ends with (TODO: Fully explain how to get systemd to recognize these files and start the service.).
---
Cloudflare... uses... workerd, but adds many additional layers of security on top to harden against such bugs. However, these measures are closely tied to our particular environment... and cannot be packaged up in a reusable way.
Durable Objects are currently supported only in a mode that uses in-memory storage -- i.e., not actually "durable"... Cloudflare's internal implementation of this is heavily tied to the specifics of Cloudflare's network, so a new implementation needs to be developed for public consumption.
...the runtime parts I was most curious about couldn't be open-sourced :(
We definitely need to provide more higher-level documentation around this, which we're working on, but if you're patient enough to read the schemas then everything is there. :)
To act as a proxy, you would define an inbound socket that points to a service of type `ExternalServer`. There are config features that let you specify that you want to use proxy protocol (where the HTTP request line is a full URL) vs. host protocol (where it's just a path, and there's a separate Host header), corresponding to forward and reverse proxies.
Next you'll probably want to add some Worker logic between the inbound and outbound. For this you'd define a second service, of type `Worker`, which defines a binding pointing to the `ExternalServer` service. The Worker can thus send requests to the ExternalServer. Then you have your incoming socket deliver requests to the Worker. Voila, Workers-based programmable proxy.
Again, I know we definitely need to write up a lot more high-level documentation and tutorials on all this. That will come soon...
absolutely key point here. miniflare doesn't allow you to check for conditions in which cloudflare might not fulfill a promise, but can't actually be tested for as the infrastructure is simply represented as an artifact currently with miniflare
Lol, considering how many just use AWS or use Firestore or a myriad of other vendor lock in solutions for everything, sadly no-one really cares about lock in anymore.
That idea makes the implicit assertion that the only thing valuable about the code is that someone else might get it running in production, and not that they actually published their production runtime for the world to inspect, debug, and offer improvements to.
Right now, you can't use most NPM modules on CF Workers since this is a custom runtime which is also pretty barebones (probably by design).
Deno in comparison offers a rich standard library which solves plenty, but they are also working on a compat layer for Node modules. And the Deno ecosystem is also growing, probably because you can run it anywhere.