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